We recently adopted this architecture for a medium-scale project. The unidirectional data flow has greatly reduced code complexity for us. We're still not satisfied with our server syncing strategy. Seems like actions are the best place to sync data, but how do you deal with interdependent actions?
I'm the author of Fluxy and would be happy to answer any questions here. The big benefits of Fluxy vs other Flux approaches is that
1) Stores are built on top of immutable data structures (via ClojureScript / mori)
2) Server side rendering is baked in (or will be as of 0.4)
I initially thought that the suggested implementation by Facebook was a bit weird because it requires a lot of boiler plate code.
For the longest time I disliked using magic strings for type checking since it breaks the concept of polymorphism. In Javascript it is even more weird considering it is a dynamic language. So I fixed that by moving the type specifics (which in Flux's case is mostly about handling events) into the actions and stores themselves.
Thanks to a contributor we also provide a mixin for React components that adds automatic unsubscription on componentWillUnmount and provides a listenTo method in the components to subscribe to actions and stores.
It works both server-side (available at npm) and client-side (available as bower package or can be built in browserify from npm package).
Thanks for posting - I'm glad to learn about reflux here. I started adding flux to an application as prescribed and thought there were many strange and unnecessary steps. All the flux libraries seemed equally complicated. Instead I went with a simple event emitter approach, which is basically Reflux without the nice API. I will certainly give it a try.
We've been exploring Flux pretty heavily here at Yahoo and the idea of utilizing React + Flux stores on the server-side as well. The Yahoo flux-example you linked to is using our own dispatcher (https://github.com/yahoo/dispatchr) that does away with the singleton pattern all of the other Flux documentation and examples have used, making it safe to use on the server.
Usually I have an action call out to some DAO class which encapsulates an HTTP request and returns a promise, then just firing off a different action in the done and fail callbacks.
We recently adopted this architecture for a medium-scale project. The unidirectional data flow has greatly reduced code complexity for us. We're still not satisfied with our server syncing strategy. Seems like actions are the best place to sync data, but how do you deal with interdependent actions?