How can i make my webapp render server-side and send only ready-to-use html to the client, if the client didn't download main.js file yet?
On the server, use React.renderToString (https://facebook.github.io/react/docs/top-level-api.html#react.rendertostring) with the same component JSX and the same props. Then, in your server-rendered template, place the generated string of markup in the same container element where you mount your React component client-side.
React components will generate the same markup in the browser and on the server given the same props. React in the browser is smart enough (via the value of the data-react-id attribute) to recognize that a component has been already rendered to a string on the server and delivered to the browser within the initial page load. So, it won't render it again—it will just hook up the component's events.
If your HTTP server isn't Node-based, you can use a simple messaging implementation (e.g. ZeroMQ or Redis pub/sub) to send rendering requests to a tiny Node script running on the same server. This script should have filesystem access to the same JSX components that you use client-side. The Node script should accept the path to the component JSX and a props object, and return the output of React.renderToString to your main HTTP server for inclusion in a template.
Related
I recently started looking into SSR(Server side rendering) and I am impressed with its advantages. To name a few Load times, SEO, No javascript configuration.
However I am trying to understand if react server side rendering is worth it.
React is known for its Virtual DOM manipulations but using react with server side rendering will not give benefits of reactJs.
Can some one shed your ideas on using reactJS for server side rendering?
Using server-side rendering in React does not imply that React will not be used on client-side.
One of completely valid approaches is to start with client-side rendering only. In this case you have to setup a single HTML element in your HTML file that will become a hook for React once it loads.
Just to give you an example, let's say we have an <div id="root"></div> element in index.html file that will be served if we HTTP GET / path on our server. Initial document (in our case index.html) should also reference javascript file that includes React and our code. It can be done by adding something like <script type="text/javascript" src="/index.js"></script> just before </body> tag.
At some point while index.js is executed, ReactDOM.render() method is called (note: we are in the browser right now) - this is a moment in time when React looks for a div element with root id attached in a document. After it's found, it becomes react-root - component tree is mounted under this element and managed by React (ie. virtual DOM, event handlers, state updates).
Please note that this approach requires that at least one javascript file is fetched, parsed and executed before browser can render anything meaningful (other than an empty div) to a user. For some scenarios, this is not acceptable and this is where SSR (server-side rendering) can help.
Server-side rendering requires that you have JavaScript runtime environment available on your server. One of the popular choices is Node.js (others include for example Nashron for JVM).
In approach, you execute React on the server and use ReactDOMServer.renderToString() (or ReactDOMServer.renderToNodeStream()) method to generate HTML response that is sent to the client - instead of an almost empty response with just one placeholder div as previously, now you can send all the markup that will be generated from your component tree (important note here is that in React 16.4(+) only UNSAFE_componentWillMount lifecycle method is called on server-side). After the initial response with a document is sent to the client, browser can render the initial markup before index.js even finishes downloading. Once it does, ReactDOM.hydrate() method kicks in. Hydration is a process of using existing server-side rendered markup and "watering" it with javascript goodies like event handlers. After it's done, this component tree is now completely managed by React with all the benefits.
Please note that in SSR, exactly the same component tree is rendered on a server-side and that's then hydrated on a client-side.
Of course, React can also be used instead of templating engines as a very powerful static HTML markup generator. All you need to do is to render the markup on the server with ReactDOMServer. renderToStaticMarkup() and send it to the client. It should be noted that this approach has a significant performance impact (https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js) and uses a very limited number of React features.
I am working on one react application.
My requirements are :-
1) First two pages should be rendered always from server side.
2) Rest pages should be client side rendered.
For example :-
http://foo.com and http://foo.com/about I want to rendered always from server side.
http://foo.com/FAQ, http://foo.com/contact I want to render from client side.
what is the right way to achieve this?
You should use ReactDOMServer and specificly renderToString() method.
ReactDOMServer.renderToString(element)
Render a React element to its
initial HTML. This should only be used on the server. React will
return an HTML string. You can use this method to generate HTML on the
server and send the markup down on the initial request for faster page
loads and to allow search engines to crawl your pages for SEO
purposes.
If you call ReactDOM.render() on a node that already has this
server-rendered markup, React will preserve it and only attach event
handlers, allowing you to have a very performant first-load
experience.
I am building an isomorphic app with React that must support users without JS.
I am new in this technology and I have a basic doubt:
The server can store the components states to emulate what React does in the client-side?
I imagine this flow when the user dont have JS:
The user click a button and send a request to the server.
The server recovers the state of the app and makes changes in it.
The components listen this changes and are rendered again.
Is it correct?
Assuming that you're using react-router :
The server aims to initialize your state, to provide it the default minimum values necessary to make your application work while getting an url.
For example, if you have an application in which you want to display a user list, let say on /users URL, when you'll send your first request, the server will store the users in the react state.
After that first load, you'll be working on the client side using react-router, and making XHR request.
However, if you refresh your page, the process will start again : first load initializing the state and then client side navigation.
EDIT : Explanations =>
When you want to use react on the server, this means that you use a Nodejs server. The fact is that react-dom provides a method called renderToString that transform a react jsx component into standard HTML.
This aims to load the first call faster
Why ?
When you load a "big" JS application on the client, you have some delay time, the time your browser needs to download your JS bundle.
Server side rendering aims to avoid that behaviour, or at least, to gives the feeling that the app starts faster.
In no case you can only use react, even if you use your server side renders. Why ? . Because your events on buttons, or asynchronous load on client, or keypress are in JS language.
I am new to React and Redux . Although i know that React is just a view layer . But i saw a term "React can be used on server side rendering". What does this mean and how it works behind the scene with nodejs.Can anyone help me in getting clear the fact that "What is server side render in react".
The react-dom package includes a server module. This module allows you render your react application to a simple HTML string with reactDOMServer.renderTostring(). Basically a snapshot of your view for a given set of props:
https://facebook.github.io/react/docs/top-level-api.html#reactdomserver.rendertostring
Additionally this functions calculates a unique hash from the string it generated and appends it to the html. On the client side react can "pick up" the server generated HTML and use it as its "first render".
Though the client side first render and the server render need to produce the exact same output for react to pick it up on the client side. React can check this via the generated hash: The client side react will also generate a html string (without modifying the actual DOM, I think this is done only on the virtual DOM). Now it can also calculate a hash from its virtual DOM and compare it with the server rendered one. If they match, no rendering needs be done. If they don't, the client side react will throw away the server generated DOM and replace it with its version (and print out an error/warning).
In combination with redux this means in addition to rendering the HTML you need to pass down the state of your store (store.getState()) to the client. The client can then use this serialized state as an initial state when creating its instance of the redux store. This will lead to both renders (client + server) to match up.
If you don't need the client side to do anything and just want to create static markup on the server side, react-dom offers a renderToStaticMarkup() function:
https://facebook.github.io/react/docs/top-level-api.html#reactdomserver.rendertostaticmarkup
I am building a server-side rendering utility for react. I am not using ReactDOMServer and its associated renderToString method. Instead, I am rendering the app to a lightweight server-side DOM. Individual components can load data asynchronously (via AJAX, setTimeout, etc) and when all of the promises are resolved, I send the final HTML string to the browser. The async data is stored on a javascript variable named INLINE_CACHE for use in the client. This part works flawlessly.
On the client, the app component mounts to the document. When the child components go to load data, my data controller can see the INLINE_CACHE and resolve the promises immediately. This part works too.
When each promise is resolved, I call setState with the data which triggers a re-render. My problem is that even though the promises are resolved immediately, they are still resolved asynchronously per the A+ spec. This means that the initial render does not have all of the data it needs. A split second later (next tick, if you will), the data is there and a re-render occurs. But since the initial render doesn't match the existing markup from the server (and the associated checksum), react complains... rightfully so.
What I need to do is somehow render the app component in a detached DOM node (or virtual DOM only), wait for all promises to resolve, and then mount the node to the document. The goal is that react will attempt to reuse the existing markup rendered from the server. I know how to generate checksums and so forth - that's not the problem. I just need react to render my app in memory until I tell it to mount to the real DOM - at which point a diff occurs. Is this possible with React?