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

Question

What is the general practice of setting the initial state of the app with isomorphic applications? Without Flux I would simple use something like:

var props = { }; // initial state
var html = React.renderToString(MyComponent(props);

Then render that markup via express-handlebars and display via {{{reactMarkup}}.

On the client-side to set the initial state I would do something like this:

if (typeof window !== 'undefined') {
    var props = JSON.parse(document.getElementById('props').innerHTML);
    React.render(MyComponent(props), document.getElementById('reactMarkup'));
}

So yes essentially you are setting the state twice, on server and client, however React will compare the differences and in most cases so it won't impact the performance by re-rendering.

---

How would this principle work when you have actions and stores in the Flux architecture? Inside my component I could do:

getInitialState: function() {
  return AppStore.getAppState();
}

But now how do I set the initial state in the AppStore from the server? If I use React.renderToString with no passed properties it will call AppStore.getAppState() which won't have anything in it because I still don't understand how would I set the state in my store on the server?

Update Feb. 5, 2015

I am still looking for a clean solution that does not involve using third-party Flux implementations like Fluxible, Fluxxor, Reflux.

Update Aug. 19, 2016

Use Redux.

Answer 1

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!