Flux in pictures
We in Hexlet like ReactJS and Flux. It seems to us that this is the right direction for development. We love functional programming and pure functions, and when complex architectures are simplified through the approaches associated with them, that's cool. React already has a lot of resources on the Internet, including our practical course on React JS . The last lesson in this course is called “Unidirectional Data Distribution”, and there we come to an interesting topic that underlies the Flux architecture.
Flux is a data distribution pattern in the application. Flux and React have grown in Facebook together. Many use them at the same time, but nothing prevents them from being used separately. They were created to solve a specific Facebook problem.
We use React and Flux in our browser development environment Hexlet IDE (it is in open source), in which students perform practical tasks. Flux is simultaneously very popular and very incomprehensible to many in the world of the web. Today's translation is an attempt to explain Flux on the fingers (well, that is, the pictures).
')
First you need to understand what problem Flux solves.
A well-known example is a bug with notifications. You go to Facebook, see the notification at the message icon. Click, but there is no new message. Notification is lost. Then, after a few minutes of interaction with the site, the notification returns. Click again ... and again there are no messages. And so again and again and again.
It was not just a cyclical bug for the user. It was a cyclical problem in the Facebook team. They repaired it, and for a while the bug disappeared, but then reappeared, and so on and on: issue → fixed → issue → fixed ...
They were looking for a way to solve the problem once and for all. Do not just fix the bug, but make sure that the system does not allow such bugs to appear.
The fundamental problem lay in the mechanism of movement of data within applications.
There are models that contain data, and they transfer data to the layer that renders the data.
The user interacts with the view (views), so the view sometimes needs to update the model based on user input. And sometimes models need to update other models.
In addition, actions sometimes generate cascading changes. I imagine all this as a tense game of Pong : it's hard to know where the ball will fly (and whether it will fall outside the screen at all).
Add to this the possible asynchronous changes. One change may generate several others. It's like throwing a bunch of table tennis balls on Pong's screen, so that they fly in all directions along intersecting trajectories.
In general, this data stream horseradish debunk.
Facebook decided to try a different architecture, in which data always moves in one and only one direction. And when you need to add new data, the stream starts from the beginning. They called this architecture Flux.
This is actually a cool thing ... but in the picture above, probably not noticeable.
After you understand Flux, the picture will become clearer. The problem is that if you start to study the Flux documentation from scratch, such an illustration does not help to understand the essence. She did not help me. But a different approach helped: I started thinking about the system as a set of characters that work together to achieve a result. So here, meet these are my fictional friends.
First, introduce all in a quick way.
The first character is the creator of the action. It generates actions (actions), and all changes and interactions with the system pass through it. Want to change the state of the application or want to change the view - you need to create an action.
I represent him as an operator on the telegraph. You know what message to send, and the creator of the action formats it in such a way that other parts of the system understand.
Action has type and load. A type is one of the types defined in the system (usually, this is a list of constants). For example, MESSAGE_CREATE or MESSAGE_READ.
It turns out that part of the system is aware of all possible actions. This fact has a beneficial side effect. A new developer can open the action creator files and see the entire API - all possible state changes in the system.
The created action is transferred to the dispatcher.
Roughly speaking, a dispatcher is a large register of callback functions (callbacks, callbacks). Something like an operator on a telephone exchange. It has a list of all repositories that need to send messages. When a new action comes from the creator of the action, the dispatcher sends it to the necessary repository.
He does this synchronously, which simplifies the situation with the many balls in the game Pong, which I mentioned above. And if you need to set dependencies between repositories (so that one repository is updated before another), you can use waitFor () in the manager.
The Flux Controller is different from controllers in other architectures. The action is sent to all registered repositories regardless of the type of action. This means that the repository does not simply subscribe to certain actions. It learns about all actions and filters those that make sense to it.
The repository contains the state of the application, and all the state change logic lives inside.
I imagine the repository in the form of a meticulous bureaucrat controlling more than necessary. All changes must be made by him personally. And you cannot directly request a state change. The vault does not have setters. To request a state change, you need to follow a special procedure ... you needto write an application addressed to the director to submit an action through the action creator channel and the dispatcher.
As mentioned above, if the repository is registered with the dispatcher, all actions will be sent to it. Inside the repository there is usually a switch that checks the type of action and decides whether or not to respond to it. If the repository responds to actions, then it needs to make changes based on it and update the state.
After a change, the repository generates a change event. The controller view (controller view) learns about the state change.
Views are responsible for rendering the status to the user, as well as receiving input from the user.
The view is the presenter. He does not know about anything in the application, he knows only about the data that was transferred to him, and how to format this data so that people can understand it (using HTML).
A controller view is a kind of middle manager or agent between the repository and the view. The repository informs him of the change in state. He receives a new state and transmits it to all his species.
At the beginning - the organization. Initialization of the application occurs only once.
1. The repositories inform the dispatcher that they want to be notified of actions.
2. The controller view requests the latest status from the repositories.
3. When the repositories respond, controller views transfer these states to their child views for rendering.
4. View controllers ask repositories to inform them of state changes.
When initialization is complete, the application is ready to accept input from the user. Let's generate an action as if the user has made a change.
1. View tells the action creator to prepare an action.
2. The creator of the action formats the action and sends it to the dispatcher.
3. The dispatcher sends the action to the repositories in order. Each repository receives a message about all actions. Then it decides to respond to the action or not, and updates (or does not update) the state accordingly.
4. After changing the state, the repository notifies view controllers that are subscribed to it.
5. These view controllers ask the repository to give them an updated status.
6. After the repository transfers its state, the view controller will ask its child views to be re-rendered in accordance with the new state.
That's how I imagine the work of Flux. I hope this helps you too!
Resources
Flux is a data distribution pattern in the application. Flux and React have grown in Facebook together. Many use them at the same time, but nothing prevents them from being used separately. They were created to solve a specific Facebook problem.
We use React and Flux in our browser development environment Hexlet IDE (it is in open source), in which students perform practical tasks. Flux is simultaneously very popular and very incomprehensible to many in the world of the web. Today's translation is an attempt to explain Flux on the fingers (well, that is, the pictures).
')
Problem
First you need to understand what problem Flux solves.
A well-known example is a bug with notifications. You go to Facebook, see the notification at the message icon. Click, but there is no new message. Notification is lost. Then, after a few minutes of interaction with the site, the notification returns. Click again ... and again there are no messages. And so again and again and again.
It was not just a cyclical bug for the user. It was a cyclical problem in the Facebook team. They repaired it, and for a while the bug disappeared, but then reappeared, and so on and on: issue → fixed → issue → fixed ...
They were looking for a way to solve the problem once and for all. Do not just fix the bug, but make sure that the system does not allow such bugs to appear.
Fundamental problem
The fundamental problem lay in the mechanism of movement of data within applications.
There are models that contain data, and they transfer data to the layer that renders the data.
The user interacts with the view (views), so the view sometimes needs to update the model based on user input. And sometimes models need to update other models.
In addition, actions sometimes generate cascading changes. I imagine all this as a tense game of Pong : it's hard to know where the ball will fly (and whether it will fall outside the screen at all).
Add to this the possible asynchronous changes. One change may generate several others. It's like throwing a bunch of table tennis balls on Pong's screen, so that they fly in all directions along intersecting trajectories.
In general, this data stream horseradish debunk.
Solution: unidirectional data flow
Facebook decided to try a different architecture, in which data always moves in one and only one direction. And when you need to add new data, the stream starts from the beginning. They called this architecture Flux.
This is actually a cool thing ... but in the picture above, probably not noticeable.
After you understand Flux, the picture will become clearer. The problem is that if you start to study the Flux documentation from scratch, such an illustration does not help to understand the essence. She did not help me. But a different approach helped: I started thinking about the system as a set of characters that work together to achieve a result. So here, meet these are my fictional friends.
Meet
First, introduce all in a quick way.
Action Creator
The first character is the creator of the action. It generates actions (actions), and all changes and interactions with the system pass through it. Want to change the state of the application or want to change the view - you need to create an action.
I represent him as an operator on the telegraph. You know what message to send, and the creator of the action formats it in such a way that other parts of the system understand.
Action has type and load. A type is one of the types defined in the system (usually, this is a list of constants). For example, MESSAGE_CREATE or MESSAGE_READ.
It turns out that part of the system is aware of all possible actions. This fact has a beneficial side effect. A new developer can open the action creator files and see the entire API - all possible state changes in the system.
The created action is transferred to the dispatcher.
Dispatcher
Roughly speaking, a dispatcher is a large register of callback functions (callbacks, callbacks). Something like an operator on a telephone exchange. It has a list of all repositories that need to send messages. When a new action comes from the creator of the action, the dispatcher sends it to the necessary repository.
He does this synchronously, which simplifies the situation with the many balls in the game Pong, which I mentioned above. And if you need to set dependencies between repositories (so that one repository is updated before another), you can use waitFor () in the manager.
The Flux Controller is different from controllers in other architectures. The action is sent to all registered repositories regardless of the type of action. This means that the repository does not simply subscribe to certain actions. It learns about all actions and filters those that make sense to it.
Storage
The repository contains the state of the application, and all the state change logic lives inside.
I imagine the repository in the form of a meticulous bureaucrat controlling more than necessary. All changes must be made by him personally. And you cannot directly request a state change. The vault does not have setters. To request a state change, you need to follow a special procedure ... you need
As mentioned above, if the repository is registered with the dispatcher, all actions will be sent to it. Inside the repository there is usually a switch that checks the type of action and decides whether or not to respond to it. If the repository responds to actions, then it needs to make changes based on it and update the state.
After a change, the repository generates a change event. The controller view (controller view) learns about the state change.
Controller view and view
Views are responsible for rendering the status to the user, as well as receiving input from the user.
The view is the presenter. He does not know about anything in the application, he knows only about the data that was transferred to him, and how to format this data so that people can understand it (using HTML).
A controller view is a kind of middle manager or agent between the repository and the view. The repository informs him of the change in state. He receives a new state and transmits it to all his species.
How they all work together
Organization
At the beginning - the organization. Initialization of the application occurs only once.
1. The repositories inform the dispatcher that they want to be notified of actions.
2. The controller view requests the latest status from the repositories.
3. When the repositories respond, controller views transfer these states to their child views for rendering.
4. View controllers ask repositories to inform them of state changes.
Data stream
When initialization is complete, the application is ready to accept input from the user. Let's generate an action as if the user has made a change.
1. View tells the action creator to prepare an action.
2. The creator of the action formats the action and sends it to the dispatcher.
3. The dispatcher sends the action to the repositories in order. Each repository receives a message about all actions. Then it decides to respond to the action or not, and updates (or does not update) the state accordingly.
4. After changing the state, the repository notifies view controllers that are subscribed to it.
5. These view controllers ask the repository to give them an updated status.
6. After the repository transfers its state, the view controller will ask its child views to be re-rendered in accordance with the new state.
That's how I imagine the work of Flux. I hope this helps you too!
Resources
Source: https://habr.com/ru/post/268249/
All Articles