Hello, I'm Karsong.
In our React advanced source group, besides React, state management is the most discussed topic.
Weirdly, multiple groups said something similar:
His colleague/team leader/leader... Have him put all states in Redux/Mobx... In the
They think it's wrong, and they don't know how to refute it.
Let's talk about the relationship between Redux and Mobx and React and Vue.
Core competitiveness of products
If you meet a big boss in an elevator and he asks you,
X, what features are you working on these days?
How do you describe the feature you're working on to the big boss in the two minutes before the elevator reaches the floor?
I'm sure you'll be able to explain the general logic of the feature, rather than the specific interaction logic of a button in the feature?
You talk about logic, not interaction. Because logic is all that matters.
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 deals with the relationship between various states (e.g. upload progress, errors...) related to the field of file uploading. .
This part of the state is called the domain state.
After the logic is developed, you write unit tests based on the various domain states.
To quickly go live and verify that the feature is being used, you publish it directly as a CLI tool.
A few days later, the data verified that the feature was very popular. So you choose React as your view library and develop view interactions based on the previous logic.
During view interaction development, you need to deal with various view-related states (such as Loading explicit, open and closed...). .
This part of the state, we call view state.
As you can see, a fully functional product contains both domain state and view state. The former is required, the latter optional.
View the state in the gallery
Back to React, Vue and other visual libraries.
Since most view libraries have components as module boundaries, it is natural that 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, component 1 (yellow and green) has 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 complement each other in size, which means that their interaction logic affects each other.
For example, the length and width of component 5 is affected by component 2, component 6, and component 8.
Let's look at these components in terms of domain state (blue) :
The logic of the entire application is scattered among different components, perhaps in part in the didMount callback of component 1 or in part in the useEffect callback of component 3.
Because component 5 is a prompt box, it only has the prompt effect, so it does not contain the logic (that is, the domain state) necessary for the application to work.
When to use state management
Going back to the beginning, what kind of state should be in state management?
For view state:
A self-consistent component manages its own state (for example, component 1)
Components whose states affect each other (e.g., 5 and 2, 6, 8) are determined by application complexity and the span between components
The common state can be promoted to the common parent if the component span is close (such as sibling relationships).
If the components span a long distance and the application is not complex, they can be promoted to a common Context.
If the application is complex, consider state management solutions.
For domain state, which is naturally distributed in fragments among different components:
Simple applets can be distributed among components or promoted to a common Context
In other cases, the status management scheme is recommended
Even the subdomains in the domain state can be abstracted separately from the stateful management scheme.
For example, the domain state of the data requested by the server is more similar to cache. React can be processed using SWR or React Query.
In this article we talked about the classification of state -- domain state and view state, and there are different ways to deal with these two states depending on their nature.
Leaving all state to Redux is not a bad idea, but it can have an impact on readability, performance, and extensibility.
It is best to be able to convince colleagues/team leaders/leaders by the end of this article. If the other person insists on Redux the shuttle, remember four words for the silly person: