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, and you can start using Flux immediately without a lot of new code.
Structure and Data Flow
A unidirectional data flow is central to the Flux pattern, and the above diagram should be the primary mental model for the Flux programmer. The dispatcher, stores and views are independent nodes with distinct inputs and outputs. The actions are simple objects containing the new data and an identifying type property.
Flux Parts
- Dispatcher
- Store
- Action
- View
Dispatcher
The dispatcher receives actions and dispatches them to stores that have registered with the dispatcher. Every store will receive every action. There should be only one singleton dispatcher in each application.
Example:
- User types in title for a todo and hits enter.
- The view captures this event and dispatches an “add-todo” action containing the title of the todo.
- Every store will then receive this action.
Store
A store is what holds the data of an application. Stores will register with the application’s dispatcher so that they can receive actions. The data in a store must only be mutated by responding to an action. There should not be any public setters on a store, only getters. Stores decide what actions they want to respond to. Every time a store’s data changes it must emit a “change” event. There should be many stores in each application.
Examples:
- Store receives an “add-todo” action.
- It decides it is relevant and adds the todo to the list of things that need to be done today.
- The store updates its data and then emits a “change” event.
Actions
Actions define the internal API of your application. They capture the ways in which anything might interact with your application. They are simple objects that have a “type” field and some data.
Actions should be semantic and descriptive of the action taking place. They should not describe implementation details of that action. Use “delete-user” rather than breaking it up into “delete-user-id”, “clear-user-data”, “refresh-credentials” (or however the process works). Remember that all stores will receive the action and can know they need to clear the data or refresh credentials by handling the same “delete-user” action.
Examples:
1.When a user clicks “delete” on a completed todo a single “delete-todo” action is dispatched:
Views
Data from stores is displayed in views. Views can use whatever framework you want (In most examples here we will use React). When a view uses data from a store it must also subscribe to change events from that store. Then when the store emits a change the view can get the new data and re-render. If a component ever uses a store and does not subscribe to it then there is likely a subtle bug waiting to be found. Actions are typically dispatched from views as the user interacts with parts of the application’s interface.
Example:
- The main view subscribes to the TodoStore.
- It accesses a list of the Todos and renders them in a readable format for the user to interact with.
- When a user types in the title of a new Todo and hits enter the view tells the Dispatcher to dispatch an action.
- All stores receive the dispatched action.
- The TodoStore handles the action and adds another Todo to its internal data structure, then emits a “change” event.
- The main view is listening for the “change” event. It gets the event, gets new data from the TodoStore, and then re-renders the list of Todos in the user interface.
LINKS: