Principles of Flux

Unidirectional data flow

A defining characteristic of Flux is that data flows in a single direction. You can think of the data going through a series of transforms, the actions and the stores, before reaching its final destination, the view.

Stores have no setters

Flux stores have no direct setter methods available which means you can only mutate state through the central dispatcher. This leads to an easy to follow mental model on how state is manipulated and where it is initiated. All changes in state begin with a dispatched action.

Inversion of Control

Control lives in the stores which are domain models. The stores are informed by actions and resolve them as appropriate. Nothing outside the store knows how it manages its data helping to keep a clear separation of concerns. Stores may contain collections, singular values, or both.

Single Central Dispatcher

There is a central dispatcher which ensures only one dispatch event goes through at a time. By only having one dispatch happen at a time you’re eliminating cascading events from happening. This makes it simple to reason about what exactly happens when you dispatch an action.

All stores receive the dispatch

Every store has access to the dispatcher and can receive every action. By having all stores receive each action we gain the flexibility to set up dependencies between stores when dealing with derived data. A Flux dispatcher should expose a mechanism to handle this within the store.

Learning Resources

• The flux documentation.
• This great answer from Bill Fisher on Stackoverflow.
• A Getting Started with Flux guide.
• A Flux comparison post by Dmitri Voronianski.

Thanks to Bill Fisher and Dan Abramov for reading a draft of this post.