Server Rendering

We will use React in the examples below, but the same techniques can be used with other view frameworks that can render on the server.

When using Redux with server rendering, we must also send the state of our app along in our response, so the client can use it as the initial state. This is important because, if we preload any data before generating the HTML, we want the client to also have access to this data. Otherwise, the markup generated on the client won't match the server markup, and the client would have to load the data again.

To send the data down to the client, we need to:

  • create a fresh, new Redux store instance on every request;
  • optionally dispatch some actions;
  • pull the state out of store;
  • and then pass the state along to the client.
    On the client side, a new Redux store will be created and initialized with the state provided from the server.Redux's only job on the server side is to provide the initial state of our app.

In the following recipe, we are going to look at how to set up server-side rendering. We'll use the simplistic Counter app as a guide and show how the server can render state ahead of time based on the request.

Install Packages

For this example, we'll be using Express as a simple web server. We also need to install the React bindings for Redux, since they are not included in Redux by default.

The following is the outline for what our server side is going to look like. We are going to set up an using app.use to handle all requests that come in to our server. If you're unfamiliar with Express or middleware, just know that our handleRender function will be called every time the server receives a request.

Additionally, as we are using ES6 and JSX syntax, we will need to compile with (see this example of a Node Server with Babel) and the .

server.js
  2. import Express from 'express'
  3. import React from 'react'
  4. import { createStore } from 'redux'
  5. import { Provider } from 'react-redux'
  6. import counterApp from './reducers'
  7. import App from './containers/App'
  9. const app = Express()
  10. const port = 3000
  12. //Serve static files
  13. app.use('/static', Express.static('static'))
  15. // This is fired every time the server side receives a request
  16. app.use(handleRender)
  18. // We are going to fill these out in the sections to follow
  19. function handleRender(req, res) {
  20.   /* ... */
  21. function renderFullPage(html, preloadedState) {
  22.   /* ... */
  23. }
  25. app.listen(port)

The first thing that we need to do on every request is to create a new Redux store instance. The only purpose of this store instance is to provide the initial state of our application.

When rendering, we will wrap <App />, our root component, inside a <Provider> to make the store available to all components in the component tree, as we saw in .

The key step in server side rendering is to render the initial HTML of our component before we send it to the client side. To do this, we use ReactDOMServer.renderToString().

We then get the initial state from our Redux store using . We will see how this is passed along in our renderFullPage function.

Inject Initial Component HTML and State

The preloadedState will then be available on the client side by accessing window.PRELOADED_STATE.

We also include our bundle file for the client-side application via a script tag. This is whatever output your bundling tool provides for your client entry point. It may be a static file or a URL to a hot reloading development server.

  1. function renderFullPage(html, preloadedState) {
  2.   return `
  3.     <!doctype html>
  4.     <html>
  5.       <head>
  6.         <title>Redux Universal Example</title>
  7.       </head>
  8.       <body>
  9.         <div id="root">${html}</div>
  11.           // WARNING: See the following for security issues around embedding JSON in HTML:
  12.           // http://redux.js.org/recipes/ServerRendering.html#security-considerations
  13.           window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState).replace(
  14.             /</g,
  15.             '\\u003c'
  16.           )}
  17.         </script>
  18.         <script src="/static/bundle.js"></script>
  19.       </body>
  20.     </html>
  21.     `
  22. }

The client side is very straightforward. All we need to do is grab the initial state from window.PRELOADED_STATE, and pass it to our function as the initial state.

Let's take a look at our new client file:

client.js

You can set up your build tool of choice (Webpack, Browserify, etc.) to compile a bundle file into static/bundle.js.

When the page loads, the bundle file will be started up and will reuse the server-rendered HTML. This will connect our newly-started React instance to the virtual DOM used on the server. Since we have the same initial state for our Redux store and used the same code for all our view components, the result will be the same real DOM.

And that's it! That is all we need to do to implement server side rendering.

But the result is pretty vanilla. It essentially renders a static view from dynamic code. What we need to do next is build an initial state dynamically to allow that rendered view to be dynamic.

Because the client side executes ongoing code, it can start with an empty initial state and obtain any necessary state on demand and over time. On the server side, rendering is synchronous and we only get one shot to render our view. We need to be able to compile our initial state during the request, which will have to react to input and obtain external state (such as that from an API or database).

The only input for server side code is the request made when loading up a page in your app in your browser. You may choose to configure the server during its boot (such as when you are running in a development vs. production environment), but that configuration is static.

The request contains information about the URL requested, including any query parameters, which will be useful when using something like React Router. It can also contain headers with inputs like cookies or authorization, or POST body data. Let's see how we can set the initial counter state based on a query parameter.

server.js

  1. import qs from 'qs' // Add this at the top of the file
  2. import { renderToString } from 'react-dom/server'
  4. function handleRender(req, res) {
  5.   // Read the counter from the request, if provided
  6.   const params = qs.parse(req.query)
  7.   const counter = parseInt(params.counter, 10) || 0
  9.   // Compile an initial state
  10.   let preloadedState = { counter }
  12.   // Create a new Redux store instance
  13.   const store = createStore(counterApp, preloadedState)
  15.   const html = renderToString(
  16.     <Provider store={store}>
  17.       <App />
  18.     </Provider>
  19.   )
  21.   // Grab the initial state from our Redux store
  22.   const finalState = store.getState()
  24.   // Send the rendered page back to the client
  25.   res.send(renderFullPage(html, finalState))
  26. }

Async State Fetching

The most common issue with server side rendering is dealing with state that comes in asynchronously. Rendering on the server is synchronous by nature, so it's necessary to map any asynchronous fetches into a synchronous operation.

The easiest way to do this is to pass through some callback back to your synchronous code. In this case, that will be a function that will reference the response object and send back our rendered HTML to the client. Don't worry, it's not as hard as it may sound.

For our example, we'll imagine there is an external datastore that contains the counter's initial value (Counter As A Service, or CaaS). We'll make a mock call over to them and build our initial state from the result. We'll start by building out our API call:

api/counter.js

Again, this is just a mock API, so we use setTimeout to simulate a network request that takes 500 milliseconds to respond (this should be much faster with a real world API). We pass in a callback that returns a random number asynchronously. If you're using a Promise-based API client, then you would issue this callback in your then handler.

On the server side, we simply wrap our existing code in the fetchCounter and receive the result in the callback:

server.js

  1. // Add this to our imports
  2. import { fetchCounter } from './api/counter'
  3. import { renderToString } from 'react-dom/server'
  5. function handleRender(req, res) {
  6.   // Query our mock API asynchronously
  7.   fetchCounter(apiResult => {
  8.     // Read the counter from the request, if provided
  9.     const params = qs.parse(req.query)
  10.     const counter = parseInt(params.counter, 10) || apiResult || 0
  12.     // Compile an initial state
  13.     let preloadedState = { counter }
  15.     // Create a new Redux store instance
  16.     const store = createStore(counterApp, preloadedState)
  18.     // Render the component to a string
  19.     const html = renderToString(
  20.       <Provider store={store}>
  21.         <App />
  22.       </Provider>
  23.     )
  25.     // Grab the initial state from our Redux store
  26.     const finalState = store.getState()
  28.     // Send the rendered page back to the client
  29.     res.send(renderFullPage(html, finalState))
  30. }

Because we call res.send() inside of the callback, the server will hold open the connection and won't send any data until that callback executes. You'll notice a 500ms delay is now added to each server request as a result of our new API call. A more advanced usage would handle errors in the API gracefully, such as a bad response or timeout.

Because we have introduced more code that relies on user generated content (UGC) and input, we have increased our attack surface area for our application. It is important for any application that you ensure your input is properly sanitized to prevent things like cross-site scripting (XSS) attacks or code injections.

In our example, we take a rudimentary approach to security. When we obtain the parameters from the request, we use parseInt on the counter parameter to ensure this value is a number. If we did not do this, you could easily get dangerous data into the rendered HTML by providing a script tag in the request. That might look like this: ?counter=</script><script>doSomethingBad();</script>

For our simplistic example, coercing our input into a number is sufficiently secure. If you're handling more complex input, such as freeform text, then you should run that input through an appropriate sanitization function, such as .

Furthermore, you can add additional layers of security by sanitizing your state output. JSON.stringify can be subject to script injections. To counter this, you can scrub the JSON string of HTML tags and other dangerous characters. This can be done with either a simple text replacement on the string, e.g. JSON.stringify(state).replace(/</g, '\u003c'), or via more sophisticated libraries such as serialize-javascript.

You may want to read to learn more about expressing asynchronous flow in Redux with async primitives such as Promises and thunks. Keep in mind that anything you learn there can also be applied to universal rendering.