Introduction - FauxFlux

Faux (made in imitation) Flux. A Flux Like Application Architecture for Building User Interfaces.

Github Repo - https://github.com/FauxFlux/fauxflux

As the name suggests, FauxFlux is an imitation of the popular Flux application architecture that Facebook uses for building client-side web applications. It has some differences, but shares much of the same concepts of Flux, such as the dispatcher, the stores*, and the views.

The mental model can be described using the same diagram that comes from the Flux documentation which depicts a unidirectional data flow:

The dispatcher acts as the central hub. Actions are provided to the dispatcher when a FauxFlux instance is instantiated or after instantiation in the the registerActions method of the instance. Most often an action originates from a user interaction within the views. The dispatcher then invokes the callback for the registered action, which will make the needed updates to the store(s).

This is where Flux and FauxFlux start to differ.

In Flux, after the store responds to whichever actions were relevant to the state being maintained, the stores then emit a change event to alert the controller-views that a change to the data has occurred. Controller-views listen for these events and retrieve data from the stores in an event handler.

In FauxFlux, the data in the store is observable. This means that any changes that happen to the store can be reactedto instead of listened for. A reaction can then track any function that has one or more dependencies from the store that changed and signal when the function should execute again. This eliminates the need to emit when the store has changed because any reaction that depends on a value from the store will inherently know as soon as the value changes.

The observables in FauxFlux are handled by the wonderful MobX library. Mobx has a ton of great documentation and examples on its site that explain all the ins-and-outs of the library, so this documentation will not focus on the observable state mechanics, but instead focus on the FauxFlux api and architecture design choices.

*There is really only one store in FauxFlux, but with application design choices, a "stores" like implementation can be achieved.