Principles of Flux
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.