The data driver should be fromflux/redux
+react
This mode is becoming popular.
It is not just a data-driven system. In a complicated system, I think it solves a very critical problem: Inter-module interaction/communication. There are many articles comparing him with MVC/mvvm. I personally think there is no particular comparability, because the problems solved are different.
Previous processing mode
An example of a slightly complex point:
If there is such a page, we develop it according to the previous model. First, we implement modular development and split it into three modules: A, B, and C. Then each module has its own sub-module.
If the requirement is simple, it is better to solve the problem. Each module solves its own logic, and the decoupling is very clear. The relationship between parent and child is also very clear.
- For example, destroy
Module C
Will automatically destroy its sub-modulesC1
AndC101
.
- The relationship between modules is also clear,
B1
No andB2
There is a direct relationship between them.Module B
To pass. Likewise,Module B
AndModule
There is no direct relationship between them. They all need to pass through the outer layer.Page
Process the link.
But if there is such a demand,A2
AndB2
(User interaction) andC101
(User interaction.
In this mode, the solution is:
B2
Notification if any change occursModule B
,Module B
In notificationPage
,Page
CallModule
AndModule C
,Module C
CallC1
,C1
CallC101
ObtainC101
Data processing,Page
CallModule
,Module
Call againA2
In combinationC101
Changes the display of the obtained data.
Whether it looks like this is not the case. From the figure, we can see this relationship:
The figure shows only one of the complex interactions. Assume that we have two more modules associated with the logic:
B1
AndB2
Module impactA2
Module (yellow line in the figure)
C1
ImpactB1
Module (white line in the figure)
For example:
After three complex interactions, the communication between the entire module has become a Spider network. What's important is that every link needs to be maintained by developers, which not only affects development efficiency, but also does not maintain well, it is easy to cause bugs. If you add new requirements or adjust requirements later, the development costs are relatively high.
It can be seen that, for complex interactions or complicated inter-module relationships, such dependency on parent-child relationship communication is a great obstacle.
But what should we do? Refuse modular development? In this way, the page design is more coupled and cannot be maintained.
First, modular development is an irreversible trend. However, it is very important to solve modular communication.
Other inter-module communication solutions
At that time, the most important thing I thought about was how to solve inter-module communication, how to make interaction between modules easier, and how to make them more independent.
Solution 1:
One solution was to use a global event (Global on and fire ). In this way, no parent-child relationship is required between modules. Modules can interact with each other.
But there are some drawbacks:
- The event name must be unique.
- Whether the event will be repeated on
- Some coupling occurs between modules due to events.
- When the interaction is very complex, it will also be troublesome, or the above example,
B2
NotificationC2
After the change,C2
Notification requiredC101
Get the data once to confirm the change
Overall:
Advantage: eliminates the parent-child relationship between modules and enables simple cross-module communication.
Disadvantage: You still need to maintain complex inter-module relationships, but you can bypass parent-child dependencies.
Solution 2:
A model + component mode is shared globally. In fact, this is already very trend and data-driven. Each module shares a global model, and each component can be obtained globally, and its functional attributes can be directly used.
In fact, this mode is ideal, and any component on the page can be directly called and used.
I personally think the disadvantage is:
Added the global component function. If it is cut off, the data driver can be completed. If the module requires more functions to directly obtain the component, you still need to maintain the interaction logic between modules and other modules.
Data-driven
Let's take a look at the figure first. I feel that it can reflect data-driven.
A climbing puppet is characterized by a head, arm, foot, and golden hoop in each action. The head and arm have no direct relationship.
The data driver can also understand that the display on the page is determined by the data and has nothing to do with the rest of the page.
Let's take a look at the example above and add the data-driven design idea.
Each module between pages does not need to care about the relationship between parent and child modules. Each Independent module is determined by a global model.
Go back to the troublesome scenario above. WhenB2
When the data changes, it modifies the corresponding data in the model (verify the data of c101, and modify the data of A2 based on the changes of B2), and then the business module of A2 follows up with the data changes of A2.
The core of this design is the change of every module, all of which are handled by the model.
Then, the model corresponds to each module. Each module does not need to pay attention to the changes of other modules. You only need to pay attention to the changes in the model's own data. Therefore, the inter-module relationship chain is very simple.
The point is that when the interaction logic increases, the link chain will not increase because the module is only associated with the data in the model.
Of course, this model cannot omit complicated business logic, but all business logic will be clustered in the model. It can be understood that all operations on the page are data operations. Then each module only needs to listen for changes to the data that interest it. This listening relationship is the only link in the figure.
For another understanding, we transfer all the Direct Coupling Relationships between modules to Data. Data maintenance is far better than module maintenance.
How does a model correspond to a view?
The above page is used as an example:
Model
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
|
var page = { a: { isShow: true, children: [{ a1: { isShow: true } }, { a2: { isShow: true } }] }, b: { isShow: true, children: [{ b1: { isShow: true } }, { b2: { isShow: true } }] }, c: { isShow: true, children: [{ c1: { isShow: true, children: [{ c101: { isShow: true } }] } }] } }
|
Isshow indicates the meaning of the display. This status corresponds to the first image of the article.
When the data changes, for example, the model changes as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
|
var page = { a: { isShow: true, children: [{ a1: { isShow: true } }, { a2: { isShow: false } }] }, b: { isShow: true, children: [{ b1: { isShow: true } }, { b2: { isShow: false } }] }, c: { isShow: true, children: [{ c1: { isShow: false, children: [{ c101: { isShow: true } }] } }] } }
|
Corresponding to the following:
In other words, each data status corresponds to a page display status. What the page looks like and what the data needs to be processed. Data is the core of this page.
Data-driven development focus
The first step is to process the data structure. Because the data determines the display of the entire page, the design of the data structure is crucial. The scalability of the data structure determines the scalability of the page, if the data mode is not good at the beginning, it will be very uncomfortable for later maintenance.
The second point is to process the relationship between modules and data.
We can see that the difficulty and key point of data-driven development is the design of data structures. This is also a test of developers' capabilities. The quality of the data structure directly determines the quality of business development in the future.
Relationship between data drivers and MVC/mvvm
At the beginning of the article, there is no competition between the data-driven model and MVC from my perspective. In practice, each module can be an MVC or mvvm, the internal processing of the module is handed over to the module itself, which can be MVC or Singleton. Data-driven is mainly a logic between processing modules.
So why is the combination of data-driven and react better? Because react is further about implementing a data driver inside the module, the data in the module changes, and the module status changes accordingly.
[Switch] value of front-end data-driven