Flux is the application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework.
React components
With ReactJS, you pass properties, and it returns with the rendered DOM. If you pass different data, you will get different responses. This makes them extremely reusable and handy to combine them into an application.
Top-down rendering
But an application doesn't make much sense without data. When we build a ReactJS app, we start with a root node that takes data as a parameter and pass down its component hierarchy (ie. child components of the root).
This feature is called top-down rendering.
Props
ReactJS properties or props object is what gets passed down the component hierarchy.
State
But what if we want to notify the components at a higher level in the hierarchy if something has changed? For instance a button click.
We need something that stores the actual state of our application, something that we can notify if the state should change. The new state should be passed to the root node, and the top-down rendering should be kicked in again to generate (re-render) the new output (DOM) of our application. This is where Flux comes into the picture.
Why Flux?
Flux tries to avoid the complex cross dependencies between your modules (MVC for example) and realize a simple one-way data flow. This helps you to write scalable applications and avoid side effects in your application.
Flux has four main components:
- Dispatcher
- Stores
- Actions
- Views
Below is a diagram showing the components of Flux:
Dispatcher
According to Facebook, the dispatcher is the central hub that manages all data flow in a Flux application.
It acts as a registry of callbacks into the stores.
Each store registers itself with the dispatcher and provides a callback routine.
Stores
Stores contain the application state and logic.
Every Store receives every action from the Dispatcher but a single store handles only the specified events. For example, the User store handles only user specific actions like createUser and avoid the other actions.
After the store handled the Action and it's updated, the Store broadcasts a change event. This event will be received by the Views.
Store shouldn't be updated externally, the update of the Store should be triggered internally as a response to an Action: Inversion of Control.
Actions
Actions can have a type and a payload. They can be triggered by the Views or by the Server (external source). Actions trigger Store updates.
Actions should be descriptive, and should not perform an other action - no cascading actions.
Views
Views are subscribed for one or multiple Stores and handle the store change event.
When a store change event is received, the view will get the data from the Store via the Store's getter functions. Then the View will render with the new data.
Here are the steps:
- Store change event received
- Get data from the Store via getters
- Render view