universal-redux-thunk

Universal Redux Thunk

A Redux store enhancer taking care of promise resolution for building universal apps.

Background

Rendering a Redux application on the server requires you to give up on certain programming patterns. For once you can't use singletons on the server as they would be shared between multiple users. Another issue we encountered is resolving Promises trigger from actions within components. While many Redux boilerplates use custom routers to handle data fetching on the client & server we decided to approach it differently. Our goal was to surface a minimal API that can be plugged into any existing Redux application without adding limitations in the way people built their applications.

Setup

To install the stable version run:

npm install --save univeral-redux-thunk

How it Works

Universal Redux Thunk will catch any Promise returned by redux-thunk middleware. Calling renderUniversal returns a Promise which is fulfilled once all Promises are resolved. It is important to note that mutiple rendering loops will be run on the server depending on how your components are nested. For example if ComponentA has ComponentB as a child and ComponentB has ComponentC as a child, several loops will be run resolving promises in sequence on the way to the leaf child. Try not to deeply nest components with multiple slow running asynchronous actions on the way down.

This library works with a specific set of action types. This allows the library to filter actions in an attempt to detect infinte loops while rendering components, preventing excessive asynchronous actions (API calls, database queries, etc.). Before dispatching an asynchronous action the action.type should contain the word "LOADING", on a succesful response your action.type should contain "LOAD_SUCCESS" and on failure "LOAD_FAILED". This allows coverage for the three possible states of an asynchronous action.

If the same action containing "LOADING", "LOAD_SUCCESS" or "LOAD_FAILED" is detected, the rendering cycle will be aborted and an error thrown. Other action types will be ignored by the the library so you can freely dispatch as many other actions as required. All promises are tracked (promises should have corresponding actions for each of its states which can be tracked).

Guide with Redux-thunk

A small example application is provided at: https://github.com/tom-drake/universal-redux-thunk-example

Why Universal rendering?

####Faster Perceived Load Time

The network roundtrips to load all the resources take time. By already pre-rendering the first page impression the user experience can be improved. This becomes even more important in places with high internet latency.

####Search Engine Indexability

Many search engines only rely on server side rendering for indexing. Google have improved their search crawler to index client side rendered content but by rendering the page on the server you simply remove a potential point of failure in indexing.

####Code Reusability & Maintainability

Libraries can be shared between the backend & front-end.

Client side vs Universal rendering

Use case with client side rendering

• (Client) Request the website's HTML
• (Server) Serve the page without content
• (Client) Request JavaScript code based on sources in the HTML
• (Server) Serve the JavaScript code
• (Client) Load & execute JavaScript
• (Client) -> Render a loading page
• (Client) Request data based on the executed code
• (Server) Collect and serve the data
• (Client) -> Render the content

Caching definitely helps to reduce the loading times and can be done easily for the HTML as well as for the code.

Use case with universal rendering

JavaScript code is already loaded when starting the server. From experience I saw this can take a couple hundred milliseconds.

• (Client) Request the website's HTML
• (Server) Execute the JavaScript Code
• (Server) Collect the data
• (Server) Render the page in the backend
• (Server) Serve the page with content
• (Client) -> Render the content
• (Client) Request JavaScript code based on sources in the HTML
• (Server) Serve the JavaScript code
• (Client) Load & execute JavaScript

Pros & Cons

While with the initial site can be serve faster with client-side rendering there is no relvant content for the user. The network roundtrips increase the time until the user actually sees relevant content. While with the universal approach it takes a bit longer until the user receives the first page it already comes with the content and the total loading time is faster.

Initial Technical Requirements for univeral-redux-thunk

Given the user of redux-thunk it should just work. You may have to do some work to remove the infinite loop issue such as checking that a promise action has not already been dispatched, but this should be no more than a simple if check to check the loading/loaded state of your reducer leaf.

All tools must be ready to work with server-side rendering. Luckily that's the case in the React/Redux eco-sytem:

• React
• React-Router
• Redux
• Webpack or Browserify
• Superagent

License

MIT