Not a flux
I'll tell you about another interpretation of Flux, or rather about a new approach in the development of interfaces - Not a Flux. The reader is supposed to at least read the Flux documentation.
What is Flux? In short: this is not even a pattern, it is more a way of organizing the architecture of an application. Consists of store, dispatcher, view. A special feature of Flux is the unidirectional communication between system components through actions.
')
Let's take a closer look at FLUX from react and MVC.
According to the philosophy of react, allocate the controller view and view .
The controller view is the parent for the other view, which is responsible for the logic of drawing its children, receives data from the model and gives them to children in props. At the same time, Facebook engineers say that there is no controller in Flux. Ummm ... then who draws the view, who determines which view you want to display? Doesn't the Controller view do this?
In the MVC model, this is the controller that communicates with the model, receives data from it, and draws the view. In other words, the controller is an interlayer that works with data from the model, transmits them to twist and draws specific views, at a specific point in time, depending on external conditions. Which also corresponds to the philosophy of separation into components . We will not talk about those stupid controllers who do all the work or about those stupid views that also know about the model.
Stateless View or just VIew, what is it? In the new react, it became possible to create them even easier by declaring a regular function in a module, which returns the jsx template, i.e in the mvc model, this is V (view). They are called stateless functional components .
In turn, I get the data model in the props with which this View works, a kind of View Model, i.e. specially prepared data that is needed for a specific View.
Flux works with data through a central repository called Store. In turn, this is the M (Model) in the MVC pattern. The difference is that the model knows about the dispatcher, but about this a little later and at the same time the Store is the central repository for everything and everyone, and also contains a certain state application. And also, Facebook engineers say the Store contains logic, but which one?
Thus, the controller function in MVC was blurred between the controller view and the Store . Who worked with Backbone or with other frameworks, most likely faced with the problem of the need to store the state of the application. This problem can be solved in different ways, but in most cases either the main controller, or urls, or localStorage were responsible for this.
How do the children view, can signal the parent about the changes occurring in it and the actions that the user performs? Signaling can be implemented in two ways:
Action according to the philosophy of react consists of the name of this action and the data itself, which in turn resembles the usual event object in the pub-sub.
Consider a typical TODO example on a Flux site. It clearly shows that the controller is allocated, which coordinates all the actions taking place in the dispatcher, climbs to the store at the right moment (model), more precisely subscribes to events, receives data from it, again through pub-sub events and throws them to the right descendants through props . The only thing that is not clear is why should a regular button know about the Dispatcher and signal its actions? How can I reuse this button in other views? Much more flexible, it would be to use callback, and already in the parent View throw something in the Dispatcher.
So what is Flux? Flux is nothing more than a combination of the MVC / MVVM code structure pattern and the Mediator interaction pattern. The fact that this connection is unidirectional is so clear why the descendants of the controller should be aware of the model, otherwise they cannot be reused elsewhere.
In the next article I will talk about the application of Not a Flux method in a real project to react.
I suggest everyone who considers Flux to be new and is searching the Internet for various articles about Flux, like Flux for stupids, to use a completely new pattern, Not a Flux, consisting of two components: Brain and Design patterns.
Which of these can be concluded? In my opinion, one should not study flux and how to successfully use it in react applications, but study the basic patterns that are fundamental in software development, for example, structural patterns, interaction patterns, object creation patterns (factories), etc. Flux is just An example of how knowing these patterns can be an interaction between the components and an application.
Criticism of the case and pointing out inaccuracies is welcome.
Who cares, I recommend to read a couple of books (you know where to find the links), if someone has not read them:
* All pictures are taken on the Internet
First about flux
What is Flux? In short: this is not even a pattern, it is more a way of organizing the architecture of an application. Consists of store, dispatcher, view. A special feature of Flux is the unidirectional communication between system components through actions.
')
Let's take a closer look at FLUX from react and MVC.
According to the philosophy of react, allocate the controller view and view .
The controller view is the parent for the other view, which is responsible for the logic of drawing its children, receives data from the model and gives them to children in props. At the same time, Facebook engineers say that there is no controller in Flux. Ummm ... then who draws the view, who determines which view you want to display? Doesn't the Controller view do this?
In the MVC model, this is the controller that communicates with the model, receives data from it, and draws the view. In other words, the controller is an interlayer that works with data from the model, transmits them to twist and draws specific views, at a specific point in time, depending on external conditions. Which also corresponds to the philosophy of separation into components . We will not talk about those stupid controllers who do all the work or about those stupid views that also know about the model.
Stateless View or just VIew, what is it? In the new react, it became possible to create them even easier by declaring a regular function in a module, which returns the jsx template, i.e in the mvc model, this is V (view). They are called stateless functional components .
In turn, I get the data model in the props with which this View works, a kind of View Model, i.e. specially prepared data that is needed for a specific View.
Flux works with data through a central repository called Store. In turn, this is the M (Model) in the MVC pattern. The difference is that the model knows about the dispatcher, but about this a little later and at the same time the Store is the central repository for everything and everyone, and also contains a certain state application. And also, Facebook engineers say the Store contains logic, but which one?
Thus, the controller function in MVC was blurred between the controller view and the Store . Who worked with Backbone or with other frameworks, most likely faced with the problem of the need to store the state of the application. This problem can be solved in different ways, but in most cases either the main controller, or urls, or localStorage were responsible for this.
How do the children view, can signal the parent about the changes occurring in it and the actions that the user performs? Signaling can be implemented in two ways:
- via callbacks, passing them through props and calling events , for example, onChange. This strategy is well suited for the development of individual reusable interface components: buttons, selects, autocomplete, and so on.
- using the Mediator pattern via events, which in the reactor were called actions. Yes, it is mediator in the pub-sub pattern that serves as a kind of pipe, where a lot of events pour in, and listeners can subscribe to the necessary events and work with them. In FLUX, this is called the Dispatcher .
About Actions
Action according to the philosophy of react consists of the name of this action and the data itself, which in turn resembles the usual event object in the pub-sub.
Now to practice
Consider a typical TODO example on a Flux site. It clearly shows that the controller is allocated, which coordinates all the actions taking place in the dispatcher, climbs to the store at the right moment (model), more precisely subscribes to events, receives data from it, again through pub-sub events and throws them to the right descendants through props . The only thing that is not clear is why should a regular button know about the Dispatcher and signal its actions? How can I reuse this button in other views? Much more flexible, it would be to use callback, and already in the parent View throw something in the Dispatcher.
So what is Flux? Flux is nothing more than a combination of the MVC / MVVM code structure pattern and the Mediator interaction pattern. The fact that this connection is unidirectional is so clear why the descendants of the controller should be aware of the model, otherwise they cannot be reused elsewhere.
Life example
In the next article I will talk about the application of Not a Flux method in a real project to react.
PS
I suggest everyone who considers Flux to be new and is searching the Internet for various articles about Flux, like Flux for stupids, to use a completely new pattern, Not a Flux, consisting of two components: Brain and Design patterns.
Which of these can be concluded? In my opinion, one should not study flux and how to successfully use it in react applications, but study the basic patterns that are fundamental in software development, for example, structural patterns, interaction patterns, object creation patterns (factories), etc. Flux is just An example of how knowing these patterns can be an interaction between the components and an application.
Criticism of the case and pointing out inaccuracies is welcome.
Literature
Who cares, I recommend to read a couple of books (you know where to find the links), if someone has not read them:
- Learn Javascript Design Patterns by Addy Osmani
- Javascript Patterns by Stoyan Stefanov
- About ReactJS
- O Flux
* All pictures are taken on the Internet
Source: https://habr.com/ru/post/270193/
All Articles