With the increasing complexity of JavaScript single-page application development, JavaScript needs to manage more states than ever before. These states may include server responses, cached data, locally generated data that has not yet been persisted to the server, as well as UI states such as active routes, selected labels, whether loading activity or pagers are displayed, and so on.

Managing changing states is difficult. If a change in one model causes a change in another model, then a change in the View may cause a change in the corresponding model as well as in the other model, which in turn may cause a change in the other view. Until you can’t figure out what’s going on. When, for what reason, and how state changes are out of control. When systems become complex, it can be difficult to reproduce problems or add new features.

Much of the complexity here comes from the fact that we often confuse two difficult concepts: change and asynchrony. If you separate them, you can do well, but when you mix them together, they get messy. Some libraries such as React attempt to address this problem by disabling asynchronous and direct DOM manipulation at the view layer. The fly in the ointment is that React still leaves it up to you to handle the data in state. Redux is there to help you solve that problem.

Redux itself is simple.

Our redux general file classification is 👇

This article is based on the official documentation of the expansion,0 base friends recommend first read the official documentation ->[portal]

Action is the payload that transfers data from the app to the Store. It is the only source of store data. Typically we pass the action to the store via store.dispatch().

Reducers specifies how changes in application state can be sent to the Store in response to actions. Remember that Actions only describe the fact that something happened, not how the application updates state.

A Store is an object that ties them together. The Store has the following responsibilities:

Maintain application state; Provide the getState() method to getState; Provide a dispatch(action) method to update state; Register a listener with subscribe(listener); Unsubscribe the listener via a function returned by subscribe(listener).Copy the code

Redux apps have a single store. When you need to split data processing logic, you should use a Reducer combination instead of creating multiple stores.

Simply put: Our action submits our data, so where? Submit to our store

Our Reducers are the actions that we submit to our data changes, and their bridge is our store.js file

And both our Action and reducers have two JS files

Personally, I don’t think reducers main.js and Actiontypes.js of actions are of much use. It’s not necessary to have a clear division of everything.

(Of course I think it’s nice to have a clear division, but it feels like a hierarchical circular hell. To put it simply, beginners will be confused.

So I think it’s just fine to divide it into five categories — e.g. (data, derived data, methods (can’t change state directly), filter methods and modify (can change state), modularity)

Here’s a personal shorthand

The specific process in the picture

OnClick {()=>this.changeTab(item)} The event this.props. Dispatch (changeTab_tab({avtiveKey:item.key}) connection to the changeTab_tab is a method defined and referenced in tabActions to be triggered 3: Return type in tabAction (and the following switch-case should be removed) 4: Tabreducers in Reducers --> Internally judge and trigger our case event with switch, return the corresponding result and export(exposure)Copy the code