1. mv* mode
MVC/MVVM is referred to as MC* mode, where MVVM evolved from MVC.
MVC is an architectural design pattern that encourages improvements in application architecture by focusing on separation of interfaces from data. Specifically, MVC enforces the isolation of business data (Model) from the interface (Model), and uses the controller (Controller) to manage logic and input.
1.1 MVC structure
In the MVC model, it mainly involves 3 roles, Model, ViewandController
- Model
ModelResponsible for saving application data, interacting with the backend to synchronize application data, or verifying data. ModelDoes not involve the user interface, nor the presentation layer, but represents unique forms of data that an application may require. When Modelchanged, it notifies its observers (such as views) to react accordingly.
- View
Viewis Modela visual representation that represents a view of the current state. The front end Viewis responsible for building and maintaining DOM elements. Knowledge of and Viewin the application is limited, and the actual task of updating is on top.ModelControllerModelController
- Controller
Responsible for the connection Viewand Model, Modelany changes will be applied to Viewthe Viewoperation will be Controllerapplied to Modelthe. Overall, the logic and coordination within and between Controllerapplications is managed .ModelView
1.2 Evolution of MVVM
MVVMThe biggest change lies in VM（ViewModel）代替了C（Controller）. Its key improvement is data binding, that is, changes in the data state of the View can directly affect the VM, and vice versa.
1.3 Problems with MVC
MVC has a fatal shortcoming, which is very obvious when the project is getting bigger and the logic is getting more and more complicated, that is 混乱的数据流动方式.
2. Flux
The core idea of Flux is that data and logic always flow in one direction.
In a Flux application, the route of data from action, dispatcher, to store, and finally to view is one-way and irreversible. The setting that the setter cannot be exposed in the store strengthens the purity of data modification and ensures that the data in the store determines the unique state of the application. Flux emphasizes one-way data flow and cautious and traceable data changes.
2.1 The basic concept of flux
A flux application consists of 3 parts: dispatcher, storeand view. It dispatcheris responsible for distributing events, storesaving data, responding to events and updating data, viewsubscribing storeto data, and using these data to render corresponding pages.
Although it looks similar to the MVC architecture, it does not have a controller with clear responsibilities. In fact, there is a role in flux controller-view, but its responsibility is to bind the view and the store, and there is no responsible logic that the controller in traditional MVC needs to undertake.
2.1.1 dispatcher and action
Events in flux are distributed by several central processors, which are dispatchers.
Action is an ordinary javascript object, which generally contains fields such as type and payload, which are used to describe an event and related data that needs to be changed.
{
"type": "CLICK"
}
2.1.2 store
In flux, the store is responsible for saving data and defining the logic for modifying the data, while calling dispatcherand registermethods register themselves as a listener. In this way, whenever we use the dispatcher's dispatch method to distribute one action, the listener registered by the store will be called, and at the same time get the action as a parameter.
The store generally determines whether to respond to the action according to the type field of the action. If necessary, the data in the store will be modified according to the information in the action, and an update time will be triggered.
It should be noted that in flux, the store is only exposed to the outside getterworld setter, which means that outside the store, you can only read the data in the store and cannot make any modifications.
2.1.3 controller-view
Generally speaking, controller-viewit is the top-level view of the entire application. No specific business logic is involved here. It mainly binds with storeand viewdefines the way of data update and delivery.
When the store responds to an action and updates the data, an update event is triggered, which is monitored in the controller-view. When the store is updated, the controller-view will reacquire the data in the store, and then call the setState method to trigger interface redrawing, so that all sub-components can obtain the updated data in the store.
2.2.4 view
viewIt is used to display the interface. In flux, in addition to displaying the interface, view has a special agreement: if the interface operation needs to modify data, you must use dispatcher to distribute an action. In fact, there is no other way to modify data in flux other than to do so.