Hello, I’m Carson.

Besides React, state management is the most frequently discussed topic in our React Advanced Source Group.

Oddly enough, several of the group members said something along the lines of:

His colleague/group leader/leader… Let him put all the states in Redux/Mobx… In the

They feel wrong, but they don’t know how to argue.

Today we are going to talk about the relationship between state management libraries such as Redux and Mobx and view libraries such as React and Vue to solve these problems.

Core competitiveness of products

If you meet a big boss in an elevator and he asks you,

Little X, what features are you working on recently?

How do you describe the feature you’re developing to your boss in the two minutes before the elevator arrives on the floor?

I am sure you will introduce the general logic of the function, and not the specific interaction logic of a button within the function, right?

You talk logic, not interaction. Because logic is the most important thing.

Let’s look at the relationship between logic and interaction through a short story.

The relationship between logic and interaction

One day, your boss asks you to develop a file upload feature.

The development process is all about dealing with the various states related to file uploads (upload progress, errors, etc.). .

This part of the state is called the domain state.

After the logic is developed, you write unit tests based on various domain states.

To quickly go live and verify that the feature is not in use, you release it directly as a CLI tool.

After a few days, the data verified that the feature was very popular. So you choose React as your view library and develop view interactions based on your previous logic.

During the development of view interaction, various states related to the view need to be handled (such as Loading, open and close state…). .

This part of the state is called the view state.

As you can see, a fully functional product includes domain state and view state. The former is required, the latter is optional.

View the status in the gallery

Back to React, Vue, etc.

Since most viewing libraries use components as module boundaries, it is natural that the domain state and view state are split into different components, but the way they are split is completely different.

For example, a complete application can be divided into many components:

Look at these components from a view state perspective:

Comparing the two figures above and below, component 1 (yellow and green) is of the same size, indicating that it is a pure component with consistent interaction logic (such as a switch) whose interaction logic does not depend on other components.

In addition to component 1, more components need to be size complementary to other components, which means that their interaction logic affects each other.

For example, the length and width of component 5 are affected by component 2, component 6, and component 8, which may represent that component 5 is a prompt box, and whether it pops up is affected by component 2, 6, and 8.

Let’s look at these components again from the perspective of the domain state (blue) :

The logic of the entire application is scattered across different components, perhaps part of it in the didMount callback for component 1 and part of it in the useEffect callback for component 3.

Because component 5 is a prompt box and only has a prompt effect, it does not contain the logic necessary for the application to work (that is, the domain state).

When to use state management

Back to the beginning, what kind of state should be in state management?

For view state:

  • A state self-consistent component manages its own state (for example, Component 1)
  • Components whose states affect each other (e.g., 5 vs. 2, 6, 8) are determined based on application complexity and span between components

If the component span is close (if sibling), the public state can be promoted to the common parent component.

If the components span a long distance and the application is not complex, they can be promoted into a common Context.

If the application is complex, consider a state management solution.

For domain state, since it is inherently fragmented across different components:

  • Simple small applications can be left to be distributed among components, or promoted to common onesContextIn the
  • In other cases, a state management scheme is recommended

Even subdomains of the domain state can be abstracted out and handled separately from the stateful management scheme.

For example, the domain state of data requested by the server, which is more like caching, can be handled using SWR or React Query in React.

conclusion

In this article we talked about the classification of states – domain state and view state – and there are different ways to deal with these two states depending on their nature.

While it’s not a bad idea to dump all the state into Redux, it can have an impact on the readability, performance, and scalability of your project.

To be able to convince colleagues/group leaders/leaders that it is best to finish this article. If the other person insists on Redux, remember four words of wisdom when dealing with such a person who is holding (silly) :