Flux is one of the hottest topics as well as confusing in current web development. This article will try to explain Flux in the simplest way.
First, I will explain the problem that Flux was born to solve. Flux is a model for processing data in your application. Flux and React are both developed at Facebook. Many programmers often use them together, but you can use them individually. Flux and React were developed to solve some of the problems that Facebook encountered.
Among those problems, the most common is the notification bar error. You login to Facebook, you will see a notification on the chat icon.
Strangely, if you click on the chat icon, there are no messages at all. After surfing the news feed for a few minutes, the message reappears. Clicking on the chat icon again … still doesn't have any messages. This problem continues into a loop.
The problem mentioned above is just a loop for users that it is also a loop for Facebook engineers. They fix this bug, everything works normally and this error appears again. The engineers continue to fix the error, then it just reappears.
# The core problem
The core problem identified by engineers is due to the way data is transmitted in the application.
Model transmits data with View
They have models to save data, then transfer data to the view to render. Because users interact through the view, the view needs to update the model based on user interaction. Models often need to update other models.
In addition, a change can trigger a series of chain changes. Imagine you're playing Pong, you won't know where the ball will hit (or fall off the screen).
View updated model. Model update another model. It is like a ball when playing Pong
Ignoring the fact that these changes may occur async (async). A change can trigger many other changes. Imagine this is like pouring a ball bag into the screen in Pong. These balls will run wildly.
In short, the above model makes it difficult to debug the flow of data.
# Solution: one-way data stream
For the reasons explained above, Facebook tested a model, which data moves in one direction – only one way – and when you need to add new data, the process starts at the starting point. They call it the Flux model.
Diagram from Facebook's Flux documentation. It is better than you wall
Flux is really great … but you can't know just by looking at the diagram above.
Once you understand Flux, the diagram above becomes very clear. The problem is that when you learn about Flux through official documents, I don't think the diagram above will help you. The task of a diagram is to give you an overview of the system before beginning to delve into it.
I understand Flux not because of this diagram, but thinking about the system through the characters working together to achieve the goal. Today, I will introduce to you the acting part of the characters I thought of myself.
# Introduce the character
I will introduce people about characters before explaining the interaction between these characters.
# Action creator (action creator)
Note: In this article I will not translate terms directly related to Flux.
The first character is the action creator. It is responsible for creating action. Action is the way in which all changes and interactions occur. Every time you want to change the state of your app or render another view completely, you will create an action.
I liken the action creator as a receptionist of the telephone exchange. You send the information you need to transmit to the action creator, then the action creator will format the information in a way that the entire system can understand.
Action creator creates an action with an action's type and action content payload. Each type of action will be one of the action types you defined in the system (usually a list of constants – constant).
MESSAGE_READ are specific examples of actions.
When the system learns all possible actions, an inevitable consequence is a new programmaker approaching the project, opening the action creator definition file and being able to view the entire API, knowing all set of changes that may occur in your system.
Once the action creator creates an action, it will pass this action to the dispatcher.
# Dispatcher (messenger)
Basically, the dispatcher is a large directory. It was like a telephone operator at the control panel. It will keep a large book list of stores that need action. Every time the action comes from the action creator, it will pass this action to different stores.
The Dispatcher carries out its communication sequentially for each store. This helps solve the problem of many Pong balls at the same time that I mentioned above. You can set a store to receive updates before another store via
Flux's messenger is different from the messenger in other models. The action will be transmitted to all stores registered with the messenger without distinguishing the type of action. In other words, stores don't just subscribe to specific actions, they listen to all the actions and filter out the actions that interest them to continue processing.
Next is store. Store will keep all information about application state and all logic to change status in store.
I imagine the store is a civil rights officer. All state changes must be approved by this position. And you cannot directly request the store to change the state, because the store has no setter. To make a change to the state, you can only execute with a single method that is through the creator and dispatcher action.
As I said above, if a store is connected to the dispatcher, it will receive all actions. In each store there will usually be a
switch statement to classify the type of action. If this is the action that the store is interested in, it will make the necessary changes and update the state.
Once the store has applied changes to the state, it will signal to the controller view about this change.
# Controller view and view
View is responsible for receiving information from state and render interface and receiving user interaction.
View is only a representative, it does not have any sense of application logic. It only accepts data, formats and outputs into HTML markup.
Controller view acts as an intermediary manager between store and view. Store will report controller view whenever there is a change from state. It will receive the new state and pass on all the views it manages.
# Interaction between characters
# Set up
There is a small setup step for characters to interact with each other. The application only needs to do this only at boot time.
- The store will notify the dispatcher that it wants to be notified when an action is available.
- Then controller view will get the latest state from the store.
- When the controller view receives the state from the store, they send these states to the views under their management to render.
- Controller view also requires store notifications when the state is updated.
# Data stream
Once the setup process is complete, the application is ready to receive user interaction. We will start by activating an action through user changes.
- Once the user interacts, the view tells the action creator to prepare a new action.
- Action creator formats the action and sends it to the dispatcher.
- The Dispatcher will send this action to the store sequentially. Each store will be notified of all actions. Then, the store will decide whether it should handle this action or not, if so, update the state accordingly.
- When the store has completed changing the state, it will notify the associated controller view.
- Controller views will require the store to send them new updates to the state.
- After the state has been received, the controller view tells the views because it manages the render based on the new state.
That's how I think about Flux. Hope it helps you!
ITZone via khoanguyen