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!