Introduction to React Flux Architecture
Click here for an introduction to React .
What is Flux
Flux is Facebook's application framework for building client-side web applications. It utilizes one-way data flow to compose view components in React. It's more of a pattern than a formal framework, and developers don't need much new code to get started with Flux quickly.
The core part of Flux
1. dispatcher
The event dispatch center, the central hub of the flux model, manages all data flows in the Flux application. It is essentially a callback registration for the Store. Each Store registers itself and provides a callback function. When the Dispatcher responds to the Action, it sends the data payload provided by the Action to all Stores in the application through the registered callback function. Application level singleton! !
2. store
Responsible for encapsulating the interaction between application business logic and data.
-
Store contains all the data of the app
-
The Store is the only place in the app where data changes
-
There is no assignment interface in the store - all data changes are sent to the store by the dispatcher, and new data is returned to the view with the change event triggered by the store. Store only exposes getters to the outside world and does not allow setters! ! Direct operation of the Store is prohibited anywhere.
3. view
-
Controller-view can be understood as the controller in the MVC model, which is generally acted by the top-level container of the application and is responsible for obtaining data from the store and passing the data to the child components. Simple applications generally have only one controller-view, and complex applications can have multiple ones. The controller-view is the only place in the app where you can manipulate state (setState())
-
view (UI component) ui-component has a single responsibility and allows calling action to trigger events, and data is passed from the upper container through properties.
4. Other
Action creators, as auxiliary functions of dispatcher, can usually be considered as the fourth part in Flux. ActionCreators are relatively independent, and as a syntactic helper function, it is more convenient for dispatchers to pass data in the form of actions.
How Flux(Unidirectional Data Flow) Works
view --> actionCreators
action dispatch
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
// NavActionCreators.js
export
default
{
clickNav(nav){
AppDispatcher.dispatch(
{
type: ActionTypes.CLICK_NAV,
nav
}
);
}
};
|
dispatcher --> store callback
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
AppDispatcher.register(action => {
switch
(action.type) {
// nav点击
case
ActionTypes.CLICK_NAV:
IndexWebAPIUtils.getGiftList(_currentUserInfo.userId, action.nav.id)
.then(
function
(giftList) {
_currentGiftList = giftList;
IndexStore.emitChange();
});
break
;
// no default
}
});
|
store emitChange --> controller view --> setState
Flux vs MVVM
MVVM
1. Simple MVVM
2. Complex MVC
Flux
1. Complex Flux
Advantages of Flux
1. Data state becomes stable and behavior is predictable
Because of angular's two-way binding, we can never know when the data is in a stable state, so we often see some problems handled by setTimeout in angular (in fact, there are more elegant solutions, which are not discussed in this article. Inside). At the same time, due to the two-way binding, it is difficult to predict the flow of behavior. When the model of the view increases, if a bunch of subviews depend on these models, the location of the problem is a nightmare (this is also angular The reason why the error message is so unfriendly, because the framework developers can't determine who triggered the current behavior, there are too many people bound...). However, it should be emphasized here that it does not mean that two-way binding will inevitably lead to an unstable data state. In angular, we can still make data stable by some means, but two-way binding (mvvm) is more stable than flux. It is easy to cause data instability problems.
2. All data changes happen in the store
In flux, the view is not allowed to directly modify the store. All the view can do is to trigger the action, and then the action will be dispatched by the dispatcher and finally flow to the store. All data changes occur inside the store component. The store only provides the get interface to the outside world, and the set behavior happens internally. The store contains all relevant data and business logic. All store-related data processing logic is centralized to avoid business logic decentralization and reduce maintenance costs.
3. Rendering of data is top-down
All data sources of the view should only be passed from properties, and all the performance of the view is determined by the state of the upper control view (controller-view). We can understand controller-view as a container component. This container component contains several small sub-components. Different states of the container component correspond to different data, and sub-components cannot have their own states. That is, after the data is passed from the store to the controller-view, the controller-view passes the data to each child view from top to bottom by means of properties through setState.
4. The view layer becomes very thin, truly componentized
Due to the reasons 2 and 3, the view itself needs to do very little. The business logic is done by the store, and the state change is done by the controller-view. What the view itself needs to do is to trigger different actions according to the interaction, and that's it. The advantage of this is that the entire view layer becomes very thin and pure, and only focuses on the interaction of the ui layer. Each view component was completely loosely coupled before, which greatly improves the reusability of the view component.
5. The dispatcher is a singleton
For a single application, the dispatcher is a singleton. The most important thing is that the dispatcher is the data distribution center. All data needs to flow through the dispatcher. The dispatcher manages the relationship between different actions and the store. Because all data must be left in the dispatcher, we can do a lot of interesting things based on this, various debug tools, action rollback, logging and even permission interception are all possible.
Flux's dilemma
1. Too much boilerplate code
flux is just an architectural pattern, not an already implemented framework, so we need to write a lot of boilerplate code based on this pattern, and the amount of code duang comes up all of a sudden. . Fortunately, there are already many useful third-party implementations based on flux, and the most popular one is redux.
2. The dispatcher is a singleton
The dispatcher acts as the event distribution center in flux and also manages events in all stores. When there are many events in the application, the management of the event sequence becomes complicated and difficult to maintain. There is no unified place to clearly express which stores are managed by the dispatcher.
3. Where is asynchronous processing written?
According to the flux process, it is processed in the action: the components that depend on the action are forced to be coupled into the business logic
Processed in the store according to the store's responsibility: the store state becomes unstable, and the dispatcher's waitFor fails
4. No official implementation yet
write at the end
Front-end Moore's Law: Front-end difficulty doubles every 18 months