React relies on the data-react-checksum attribute for reusing markup, which is only set in renderComponentToString (used for server-side rendering of components).
How can I reuse the react-component markup when the component is rendered client-side only?
Background
I'm working on a client-side only webapp. One of the project's goals is to render as quickly as possible, reducing UI "lag" from uninitialized elements, JS loading/parsing, and so forth.
I'm want to cache the rendered react-components markup using localStorage so the previous UI state can be restored as early as possible (again for performance reasons without waiting ~200ms for react to be loaded and parsed).
Strictly speaking, there's no way to turn a string of markup into a live React component (at least not in a performant way). Plus, it doesn't really make sense as your component might have had hidden state that aren't shown on the final rendered DOM string. If you try to revert the string into a component, it'll lead to state inconsistencies.
Something neat to do is to serialize your data into localStorage, and then reproduce your components from that data. But this more or less helps in your case.
But still, you can roll your own small logic on putting the string markup, then letting React destroy it subsequently by rendering a second time.
Related
With SSR, JavaScript must be fetched for interactivity, which is often achieved via hydration. How will this be achieved with server components?
React server components don't have state, event handlers, etc. and cannot themselves be interactive. But they can be interleaved with client components, which can be interactive.
Also - React server components still require Javascript. Even for server components, even though no bundles are sent down, they are still "hydrated" in the sense that they are turned into JSX elements and then rendered onto the page as part of the React tree.
See https://blog.plasmic.app/posts/how-react-server-components-work/ for a complete look:
Why invent a whole new wire format? The goal on the client is to reconstruct the React element tree. It is much easier to accomplish this from this format than from html, where we’d have to parse the HTML to create the React elements. Note that the reconstruction of the React element tree is important, as this allows us to merge subsequent changes to the React tree with minimal commits to the DOM.
I currently have a React app that I'd like to use SSR with. All but one component is pretty much static content, making SSR super easy. Everything but the component is rendered just fine and well right now.
My question is how do I go about rendering this component that needs to first get data? Because it's a complex SVG that gets rendered my line of thinking is that having it "update" once data comes in is a bad move, and it would be better for it to just not exist in the absence of data (with an error message).
So here's my plan: I can add a prop to the component to pass in data from a parent rather than keep it as internal state only. So if data is passed, no fetch request in the component is necessary. From there what I can do is take the static bundle output of the app and, when the page is requested, the server will request the proper data just as the component would. Once the data is received, the server can grab the component from the bundle with regex, add the data as a prop, render the component, and stick it back in with the rest of the already rendered static content.
Is this the correct way to do this? It feels a bit complicated, but that might just be how it's done. I'm not sure.
Your intuitions are correct. In current React (17.0), it's quite cumbersome to do SSR with data-fetching inside components.
What needs to be achieved on a conceptual level is that all data dependencies need to be known upfront, ie. before calling ReactDOM's render. This way, one can access the data in a synchronous manner which allows to do one-pass render on a server.
I don't quite follow your idea to "grap the component from the bundle with regex". One way of solving the data dependency problem is to inject the data into React tree from the root component (ie. ReactDOM.renderToString(<App componentStaticData={data} />)) and make the data-dependent component aware of the fact that it can just grab the data from there instead of doing (asynchronous) call. It's important to note that useEffects are not executed on the server.
Another idea to grab all the data dependencies is to do two-pass render. First one is used as a way to collect all resources used, then we await their completion and inject them as static data into send pass.
Third way is to use one of the React frameworks that provide SSR out of the box. You can have a look at (among many others) Next.js or Gatsby. Depending on your setup, this might be easiest or the hardest way to achieve SSR.
I'm fairly new to react; just learning it. From what I understand react gives you ability to render data more dynamically. But couldn't this be achieved using flask rest api endpoints? Kind of making AJAX calls and rendering it's response dynamically?
What's the difference?
I'm currently trying to develop a full stack application. Trying to choose what I should use for frontend, typically on a normal day I tend to use pure HTML/CS/JS to accomplish most of my front-end task without having to use JS libraries such as react to render data dynamically, I want to improve my ways around handling front-end stuff hence wanted to learn more about react and how it can benefit me; before actually diving in it.
What can help is; if someone can lay it out for me; describing work scenario using reactjs and how I can be benefiting from using the js library.
Thanks.
In my opinion, React is all about how effectively you can render your dom elements.
Rendering DOM (Painting your webpage with your HTML elements) is considered to be one of the costliest operation. And if you consider using other libraries( apart from react), there is a chance that your HTML will be rendered even if it doesnt change.
Here comes the power of React. React uses the concept of Virtual DOM which helps in rendering HTML to browser only when there is a change. For example, if you have a list of items being displayed, and if one list item changed because of some action, React will trigger a change to render only that element(of course we write very minimal code for this).
So if you use React as your front end library, you can easily benefit fast rendering of HTML and stopping unnecessary rendering of your DOM
I was experimenting with React and rerendering iframes and I was not sure how React correctly rerenders iframes, especially ones which point to a text editor. Here is a jsFiddle showing this:
https://jsfiddle.net/augburto/fkqnm329/2/
The text editor I point to is not important but what I am doing is when you click Trigger Update, it will call a setInterval which will constantly set a new state and thus trigger a rerender.
What I thought might happen is that when I'm typing in the iframe which has a textarea, it will inevitably rerender and thus make me lose my text editor position but somehow I am able to type seamlessly without any issues despite seeing the rerenders come through in the console.log. Note I'm not suggesting it should do this -- I'm just wondering why it doesn't do that. I know React internals do some smart things like transactions but I wouldn't expect it to maintain my cursor position or what I have selected.
So how does React handle rerendering iframes more specifically? I have read articles (i.e. this and this but they don't shed a lot of light on it I feel). Is it any different from regular DOM elements?
Okay so after some time, I think I believe I discovered the answer. In general, because React just creates a virtual DOM and does a diff behind the scenes, it really is only looking at the iframe element and not what is generated. That is a completely separate thing where the iframe creates its own browsing context. Reading the MDN documentation on iframe was really informative:
The HTML element represents a nested browsing context, effectively embedding another HTML page into the current page. In HTML 4.01, a document may contain a head and a body or a head and a frameset, but not both a body and a frameset. However, an can be used within a normal document body. Each browsing context has its own session history and active document. The browsing context that contains the embedded content is called the parent browsing context. The top-level browsing context (which has no parent) is typically the browser window.
I think React does do some special things when it comes to parsing an iframe but overall it doesn't deviate too much in general.
Also something that I think might be informative is how React handles input elements in general -- take a look at Controlled Components in general for Forms as React has a completely separate and special way of handling those cases.
is performace degraded if we use jquery with reactjs?
because jquery changes directly DOM elements where as reactjs works with Virtual DOM.
is there any example reactjs with jquery?
is performace degraded if we use jquery with reactjs?
Not necessarily.
because jquery changes directly DOM elements where as reactjs works with Virtual DOM.
You are correct that jQuery does not utilize React's virtual DOM. Aside from rewriting core parts of jQuery to utilize it, vanilla jQuery will not. A wrapping component that does participate in React's virtual DOM can patch it in though.
The performance of this entirely depends on your usage. Keep in mind that React does still manipulate the DOM at the end of the virtual DOM work.
You can find the most up to date, official example at the Use React with Other Libraries page of the official React docs but it is admittedly light on the details.
is there any example reactjs with jquery?
If you check out this unit of react-training on wrapping DOM[-manipulating] libraries you can find a beautiful, comprehensive example of using ReactJS with both jQuery and jQuery UI.
Using the result of that article as a baseline, you will be using jQuery at time of React's initial mount time to minimally to do the DOM work and provide classnames for styling as needed, and React's pre-render props changing lifecycle event to re-render from changes through React. You are obviously free to use other events, such as shouldComponentUpdate or manually triggering renders as well, as your needs dictate.
Your performance will largely be tied to what you do in that re-render step.
Here are some tips that may help stave off some common performance vampires:
Ensure you are caching selectors and functions wherever possible
Ensure collection member's identities are properly keyed so that they aren't resulting in constant cache misses and thus constant re-renders
Especially if you are using unidirectional data flows or immutable data stores.
Some mapping operating always return new objects and so need extra care or a different api call.
Aside from that, keeping in mind both React best practices and jQuery best practices will take you a long way.
At the end of the day it's just JavaScript - React tries to keep away unnecessary heavy true DOM object creation/manipulation where jQuery allows misusing it just fine - but there is nothing by its nature to prevent making a performant jQuery app.