"Turn" talking about react, Flux and Redux

This article from the "talking about react, Flux and Redux", reproduced please indicate the source.

React

React is a view layer frame that is used to render views, which mainly do several things:

• Component of
• Using props to form unidirectional data streams
• Update the view according to the state change
• Using virtual DOM to improve rendering performance

In front of the React can update the view according to the state changes, generally caused state changes in addition to the action from outside (such as the server), most of them from the page of user activity, how the user activity on the page to the state? Each component in React has a setState method for changing the current state of the component, so the logic for changing the state can be written in its own component, but the problem is that when the logic of the project becomes more complex, it will be difficult to sort out the state and view (A state change can cause multiple view changes, and an event triggered on a view may cause multiple state changes). We need to manage all the situations that cause state change, so we have Flux.

Flux

Flux is an application architecture, or a thought, that has nothing to do with React itself, it can be used on React, or it can be used in other frameworks. As mentioned above, Flux is mainly used in React to unify the management of state changes. Flux maintains one or more variables called Store , like the Model in MVC, where all the data used by the application is stored, and when an event is triggered, Flux handles the event, updates the store, and when the store changes, it is usually the root component of the application (also called Controller view) to get the latest store, then update the state, and then take advantage of the React one-way traffic feature layer to pass the new state down to implement the view update. There can be more than one controller view here and not a root component, but the data flow is more cumbersome to maintain.

Flux's thinking model is as follows:

Flux mainly consists of four parts,,,, Dispatcher Store View Action wherein Dispatcher is the core hub of flux, it is equivalent to an event dispatcher that collects the logic code scattered in the various components, unified in the Dispatcher In the process. The complete Flux process is this: the user receives an action and executes a callback that has already been registered by interacting with the view or externally producing a action,dispatcher to distribute the action to all stores. Through registered callbacks, the Store responds to actions that are related to the state they are saving. The Store then triggers a change event to alert the controller-views that the data has changed. Controller-views listen for these events and retrieve the data from the Store again. These controller-views call their own setState () methods, re-render themselves and all descendant components on the component tree. One advantage of using Flux is that I only need to use the Action object to describe the current event to Dispatcher to execute the corresponding logic, because Dispatcher is the processing center of all actions, and even if no corresponding event occurs, we can "forge" one out, Very good for testing.

Redux

Redux the role of flux is the same, it can be seen as a flux of a realization, but a little different, the concrete difference summed up is:

　　1.Redux has only one store.

In Flux there will be multiple store store application data, and in the store to carry out the update logic, when the store changes to notify Controller-view to update their data, Redux the store into a full store, and can be based on this A store to derive the full state of the application. Also, the updated logic in Redux is not executed in the store but is placed in reducer.

　　2. No Dispatcher

　　There is no concept of Dispatcher in Redux, it uses reducer to handle events, and reducer is a pure function, which is expressed as a (previousState, action) => newState new state based on the status of the application and the current action. There are multiple reducer in the Redux, each reducer is responsible for maintaining a portion of the application's overall state tree, and multiple reducer can combineReducers synthesize a root reducer by method, which reducer is responsible for maintaining the complete state, when a acti On is emitted, the store calls the dispatch method to pass the action,reducer to a particular reducer, executes the corresponding update logic after the action is received, and then returns a new State,state update that will eventually be passed to the root reducer , return a completely new, complete state and pass it to view.

In my opinion, the biggest difference between Redux and flux is the abstraction of Store/reducer, Flux store is fighting each other, each store is responsible for the corresponding Controller-view, each update will only notify the corresponding Controlle R-view, and Redux in each sub-reducer is the root reducer unified management, each sub-reducer changes to go through the root reducer integration. It can be like this with a graph:

The store in Flux is like this:

The store in Redux (or reducer) is like this:

PS: Just contact React, many places are not particularly in-depth, if there are errors and omissions, welcome to correct.

"Turn" talking about react, Flux and Redux