preface

In my previous articles, I mentioned the failure of the current React state management strategy and the confusion of the community. In this article, I will further analyze the nature of the React state management demands and the reasons why the current official and community strategies are inadvisable. And about our team’s exploration of state management strategies and the latest practices.

The body of the

React states manage the nature of claims

If we only talk about React state management, most people may express their opinions and it is difficult for them to reach a consensus on different strategies. Therefore, let’s change our perspective and start from the nature of management demands.

First of all, the essence of the need to manage something is that the number and variables of things being managed are so complex that when we talk about the word management, in a broad sense includes

  • The self-management of things
  • Management in a narrow sense, the manager and the managed

For the React state, things here are approximately equal to the React component. And the state is part of that component.

function ReactComponent(){
    const [state, setState] = useState('jacky')
    return(
        <div>{state}</div>)}Copy the code

We know that if a team has only one person, we usually do not require a manager. The same is true for React components. A single React component has its own state name, and the component manages its own state, such as changing the name through its own Button

function ReactComponent(){
    const [state, setState] = useState('jacky')
    onClick = () = > {
        setState('ann')}return(
        <div>{state} <button onClick={onClick}>Change name = 'Ann'</button></div>)}Copy the code

Usually this self-managed state of cohesion is relatively ideal. In other words, if the variables and quantities are coming from us, then if we’re disciplined, we can’t go wrong. In this case, the biggest problem is just our own, each component’s state management policies tend to be self-restrictive.

But in any case, we can’t just be ourselves. Also, a React app naturally has so many components that the need for state management arises

Management ≠ Leadership

And appeal to different real team management, for the team, the manager is not only, more important is to correct leadership team, but simply just about state management about management, so we need to cast to what we understand about leadership in team management part of the perceptual, rational view of management of it.

When viewing an application as a team, the first step for managers is to get the team members on the same page, which in the case of the React component is state synchronization

The React community’s mainstream understanding of status synchronization is consistent with the official management strategy, which is commonly referred to as status promotion

I’ve written a code example for this, although everyone knows what a state boost is, but I’ve listed them for comparison, right

Code sample

In example1, we show two normal React components, A and B, wrapped in example1. Example2 explains what state promotion is, which is what we do most of the time, which is to strip the states of A and B, We want to give props to A and B, and we want to give props to A and B

From the React team’s own technical point of view, this might not be a problem, and it might sound reasonable. The state consumer component would be Stateless and the control component would be Smart.

But in fact, if you put this strategy into the context of team management, you will see how stupid it is

This can work in simple scenarios, but as the size of the team (application) grows, you need to provide a promotion node Container for any two nodes that need state synchronization.

In fact, our real demand is to enable B to synchronize the state of A, but the price we pay for this is an extra Container and A non-existent responsibility (additional management after state promotion), which turns the problem that can be solved by using state into, State → props → state.

So since multiple containers are not feasible, is it possible to unify them into one Container?

In fact, that can lead to bigger problems.

A centralized single Container can be a bottleneck for the entire application.

States are part of components, inseparable, like the mind and body, and it is not practical to manage them separately.

In my previous articles, I have maintained that state is part of the component and that there is no independent state management strategy, or that the pattern of managing state separately from the application and component is itself unsustainable and unsustainable.

Pure state management itself contains only two issues

  • Synchronization of states
  • The syncopation of states

In fact, neither of these things can be done well without components, and the community’s current state management strategy is all based on the premise that state is a separate part of the component

Based on this premise, there will be no solution to the above two problems, i.e

  • Synchronization of states requires additional nodes to establish communication relationships
  • The shard of the state can never be shard of the Match component

Because of the complexity of the 2B business, we abandoned the community mentality that there is no state management, only component management

Manage state based on components

Example3 and Example4 in the examples I wrote explain this point of view. When we technically view state and components as one, we find new solutions to the above problems that address both of my core propositions

  • State synchronization does not depend on additional nodes
  • State shard natural and component shard match

For state synchronization, we use a feature called linkable to solve the problem of state synchronization between different components. In Example4, we show how to use connect to manipulate components to achieve state synchronization

As you can see from my previous graph, the key is that we have changed the component communication structure from a tree to a single linked list with a new premise and a new management strategy

The latter

Our team has been committed to exploring and practicing the development of application framework based on React under complex applications. This part is part of our recent practice and thinking. Let me share and introduce some ideas. Join us at 😁 attach link github.com/kinop112365…