0. Facebook’s Flux code
1. Yahoo’s Dispatchr
Dispatchr is a Flux dispatcher written by Yahoo. Here’s how it differs from Facebook’s:
Dispatchr’s main goal is to facilitate server-side rendering of Flux applications while also working on the client-side to encourage code reuse. In order to isolate stores between requests on the server-side, we have opted to instantiate the dispatcher and stores classes per request.
In addition, action registration is done by stores as a unit rather than individual callbacks. This allows us to lazily instantiate stores as the events that they handle are dispatched. Since instantiation of stores is handled by the dispatcher, we can keep track of the stores that were used during a request and dehydrate their state to the client when the server has completed its execution.
Lastly, we are able to enforce the Flux flow by restricting access to the dispatcher from stores. Instead of stores directly requiring a singleton dispatcher, we pass a dispatcher interface to the constructor of the stores to provide access to only the functions that should be available to it: waitFor and getStore. This prevents the stores from dispatching an entirely new action, which should only be done by action creators to enforce the unidirectional flow that is Flux.
Dispatchr is used in the new version of Yahoo Mail. Here’s a slide deck about Yahoo Mail switching to React + Flux:
marty.js is another Flux implementation. It provides state management (via stores), dispatcher, and action creators. It also has a special debugging tool for Chrome that can show the state of stores and how actions flow through the stores into views.
3. Tuxx (Tuxedo.js)
Tuxx is a feature complete framework built on the React view layer, Flux Architecture, and CommonJS modules.
Tuxx also provides actions, stores, and React classes that automatically connect them.
Reflux is a library for unidirectional data flow architecture inspired by Flux. Reflux is similar to Flux in that it has actions and stores, but differs in these ways:
- The singleton dispatcher is removed in favor for letting every action act as dispatcher instead.
- Because actions are listenable, the stores may listen to them. Stores don’t need to have a big switch statements that does static type checking (of action types) with strings
- Stores may listen to other stores, i.e. it is possible to create stores that can aggregate data further, similar to a map/reduce.
waitForis replaced in favor to handle serial and parallel data flows:
- Aggregate data stores (mentioned above) may listen to other stores in serial
- Joins for joining listeners in parallel
- Action creators are not needed because RefluxJS actions are functions that will pass on the payload they receive to anyone listening to them
If you’re using any of these projects, please let us know what you think about them in comments.