React + Flux and Server-side rendering? (Isomorphic React + Flux) React + Flux and Server-side rendering? (Isomorphic React + Flux) reactjs reactjs

React + Flux and Server-side rendering? (Isomorphic React + Flux)


Take a look at dispatchr and yahoo's related libraries.

Most flux implementations don't work in node.js because they use singleton stored, dispatchers, and actions, and have no concept of "we're done" which is required to know when to render to html and respond to the request.

Yahoo's libraries like fetchr and routr get around this limitation of node by using a very pure form of dependency injection (no parsing functions for argument names or anything like that).

Instead you define api functions like this in services/todo.js:

create: function (req, resource, params, body, config, callback) {

And actions like this in actions/createTodo.js:

module.exports = function (context, payload, done) {    var todoStore = context.getStore(TodoStore);...context.dispatch('CREATE_TODO_START', newTodo);...context.service.create('todo', newTodo, {}, function (err, todo) {

The last line indirectly calls the create function in services/todo.js. In this case indirectly can either mean:

  • on the server:
    • fetchr fills in the extra arguments when you're on the server
    • it then calls your callback
  • on the client side:
    • the fetchr client makes a http request
    • fetchr on the server intercepts it
    • it calls the service function with the correct arguments
    • it sends the response back to the client fetchr
    • the client side fetchr handles calling your callback

This is just the tip of the iceberg. This is a very sophisticated group of modules that work together to solve a tough problem and provide a useable api. Isomorphism is inherently complicated in real world use cases. This is why many flux implementations don't support server side rendering.

You may also want to look into not using flux. It doesn't make sense for all applications, and often just gets in the way. Most often you only need it for a few parts of the application if any. There are no silver bullets in programming!


FakeRainBrigand is correct that the biggest problem with server-side Flux is singletons. Flummox fixes this problem by not using singletons, and enabling you to encapsulate your entire Flux set-up into a single, reusable class. Then you just create a new instance on each request. Combined with a routing solution like React Router, you can make fully isomorphic applications.

Even if you don't want to use Flummox, the source is easy to grok and you could use that as a guide to whip something up yourself:

https://github.com/acdlite/flummox


If you are willing to work with alt.js you can achieve it with alt.bootstrap and alt.flush (docs)

I'm using node js with react server side rendering and alt.js as my flux implementation.

This is how it looks:

var data = {}; // Get the data whatever you want and return it bootstrap ready.// Reminder - renderToString is synchronisedvar app = React.renderToString(     AppFactory(data));// In this point the react rendering was finished so we can flush the data and reset the storesalt.flush();

In my app.jsx

/** * */componentWillMount: function () {    // This beauty here is that componentWillMount is run on the server and the client so this is all we need to do. No need for other third-party isomorphic frameworks    alt.bootstrap(        JSON.stringify(this.props, null, 3)    );}