React state management tool

Introduction: React state management tools are various, dva, mobx, recoil, zustand. If it was you, what would you choose? Choosing an appropriate state management tool is crucial to project development, let's take a look at my options

foreword

Our front-end team has been using React deeply, from the earliest CRA, to later switching to umijs, from 1.x, 2.x, 3.x to now 4.x, one of the things that remains unchanged is that we I have been using dva based on the idea of ​​react-redux as a state management tool.

In terms of state sharing, unlike Vuex, React's official does not strongly recommend a certain encapsulation solution, so React's state management tools are varied and blooming. Among them are:

* The redux genre of dispatching everything. Including: react-redux, dva, nova on behalf of zustand
* Responsive genre mobx. And the nova stands for valtio , and a very characteristic library resso
* Atomic state genre. recoil from facebook open source, and jotai from nova
*Full body hooks genre. Hox, reto, and umijs@4 have built-in data streams, including pinia, a new state management tool officially recommended by Vue.


More importantly, the traditional MVC pattern suggests that we separate the logic layer of the view layer. In dva, pages are views, and effects are used by us to write business logic. Under the influence of this kind of thinking, we are used to creating a dva-model whether it is a simple or complex page, and dispatch is not a strong dependency. Over time, the model becomes more and more bloated, and the relationship becomes more and more difficult to find. , Tucao is getting louder and louder.

With the continuous development of technology, we finally have to get rid of cumbersome dva and find a new state management tool to reduce the amount of code in our piece and protect our hair.

So after a series of pilots, I will also introduce the advantages and disadvantages of each genre and my personal inclination.

What kind of state management tools do we need

Probably not needed?
When we read the documentation of some state management tools, we may first be thrown in the face by such an article: "You may not need a state management tool".

Yes, we shouldn't abuse state management tools, whether it's the cumbersome dva or the more concise recoil . Abuse will only cause trouble for our later maintenance and refactoring.

when do you needit?

The role of the state management tool is to share the state. When the shared state changes, all users will trigger re-rendering. So, of course, the state management tool is only needed when the state needs to be shared by multiple parties. for example:

*Currently logged in user information, name, role, organization, etc.
* caching of static data dictionaries
*Requires keep-alive data (not necessarily used)
*The function of the page is complex, after modularization, the data still needs to be shared between the modules

Please do not use shared state in [Basic Component], [Basic Component] should maintain its own independence and achieve high cohesion

Requirements for a state management tool?

With the accumulation of project experience, I have summarized several characteristics that state management tools should meet:

*Shared state (basic), which can satisfy several scenarios listed above;
*Share business logic, for example, you need to log out and jump to the login page after changing the personal password (call both in the menu bar and the personal center, the same logic should not be written multiple times);
* Shared state modularization, that is, according to different business logic, separate different files to create shared state.
*More complicated, it involves the dependencies between shared states. For example, when I modify the role of the current login person (such as switching from "project manager" to "system administrator"), the state of the record menu permissions also needs to be updated.
* When used, there is a clear source of dependencies (import from).
* Good support for TypeScript, easy to write.

How do mainstream state management tools do

Comparing dva and Vuex can not be said to be very similar, it can only be said that they are exactly the same.

The state of dva and the state of Vuex are used to store the state that needs to be shared.

dva's reducers and Vuex's mutations for writing methods that modify shared state.

dva's effects and Vuex's actions are used to write methods with side effects, such as handling asynchronous business logic.

dva uses the namespace attribute to mark the name of the submodule, and Vuex uses the modules attribute to split submodules.

advantage

In the environment where there was no hooks API at that time, it was a good integration solution, which could meet the vast majority of shared business scenarios.

Deep integration of redux redux-saga , so that redux users can switch quickly.

shortcoming

Used without a clear source

dva uses the hoc connect method to inject the properties in the store into the props of the component. As shown in the figure below: From the perspective of JS, the source and type of products are very unclear.

Not friendly to TypeScript support

Without clear dependencies, type support is naturally poor.

Dependencies between shared states cannot be satisfied

For example, if I modify the current user role, I need to re-query the accessible menus according to the role permissions. But I can't listen in the menu store, I can only actively trigger the menu query in the user store, or write a separate component, use componentDidUpdate to listen to the user store and then initiate the request.

zustand
zustand with 22K stars is a great alternative to traditional pie.

Basically the above shortcomings are solved.
Responsive genre mobx

The emergence of mobx has brought a great impact on redux.

Through a decorator (observer / observable), ordinary components can be rendered to listen for changes in variables, completely abandoning state 。 Not only that, mobx provides some good things like computed, so that React can also use the features of Vue components. And students who switched from Vue to learn React will applaud mobx.

After experiencing the refreshment of mobx, there were some voices in the team at that time, hoping to abandon the state in the future and use mobx as the component state in an all-round way. Yes, a set of solutions to solve the two problems of internal state and shared state, why not do it.

regret

Soon, the mobx-king voice faded away again because...

Responsive API and React are not acclimatized. React needs setState to modify the state. Now you have changed state.value++. Are you going to rebel? The new classmates finished learning the basics of React. As a result, he told him that those who are not needed, let's learn mobx responsiveness. Will the new classmates be full of question marks in their hearts?

There will be some hidden pits. For example, when adding properties to observable, it cannot be added directly, but through extendObservable , many of our students have stepped on this pit.

If the basic component also uses mobx, it violates the principle of high cohesion. If it is not used, the styles on both sides are not uniform. What component library have you seen that needs to come with a set of state management tools?
Responsiveness is actually implemented based on Proxy. I clearly want to pass an array, but what I get is a Proxy. Obsessive-compulsive disorder is unbearable.
So, mobx is great, but I just can't love it.

Atomic state genre recoil

After experiencing recoil, I can feel that recoil hopes that when you use the global state, the experience of useState is exactly the same. Yes, useRecoilState and useState are used in almost the same way, except that the default value of recoil needs to be wrapped with atom. So your atom state is globally shared.

In order to solve the requirement of shared state dependencies, recoil also provides a selector API very intimately, which is used to realize the splitting and dependencies of shared state. You can treat it as useMemo or a computed property. (Of course selector also supports writing (set) and asynchronous processing, but I haven't found a scene where it must be used)

insufficient

The concept of recoil is really simple, that is, to achieve state sharing with the habit of useState. So in this piece of business logic sharing, it doesn't seem to give a good solution. But since it is already oriented to the hooks API, custom hooks themselves can realize the reuse of business logic.