Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of "how to achieve React performance optimization from Context source code". The editor shows you the operation process through an actual case. The method of operation is simple, fast and practical. I hope this article "how to achieve React performance optimization from Context source code" can help you solve the problem.

Timing of component render

The implementation of Context is closely related to the render of components. Before we explain its implementation, let's take a look at the timing of render.

In other words, when does the component render?

The answer to this question has been discussed in when the React component render. Let's summarize it here:

In React, whenever an update is triggered (such as calling this.setState, useState), a corresponding fiber node is created for the component.

Fiber nodes are linked to each other to form a Fiber tree.

There are 2 ways to create a fiber node:

Bailout, that is, the fiber node corresponding to the previous update of the component is reused as the fiber node for this update.

Render, which generates a new fiber node after the diff algorithm. The render of the component (such as the render method call of ClassComponent, the execution of FunctionComponent) occurs at this step.

Students often ask: React each update will regenerate a Fiber tree, the performance will not be poor?

React performance is really not very good. But as you can see, not all components will render during Fiber tree generation, and some components that meet the optimization conditions will follow the bailout logic.

For example, for the following Demo:

Function Son () {console.log ('child renderings'); return Son;} function Parent (props) {const [count, setCount] = React.useState (0); return ({setCount (count + 1)}} > count: {count} {props.children});} function App () {return ();} const rootEl = document.querySelector ("# root") ReactDOM.render (, rootEl)

Online Demo address [2]

Click on the div sub-component of the Parent component to trigger the update, but child render! It doesn't print.

This is because the Son component enters the bailout logic.

Conditions of bailout

To enter bailout logic, four conditions need to be met at the same time:

1.oldProps = newProps

That is, the props of this update is all equal to the props of the last update.

Note that this is an congruent comparison.

We know that the component render returns that JSX,JSX is the syntax sugar of React.createElement.

So the return result of render is actually the execution result of React.createElement, that is, an object that contains the props property.

Even though there is no change in every parameter in the props update between this update and the last update, this update is the result of the execution of React.createElement and is a new props reference, so oldProps! = newProps.

2.context value has not changed.

We know that in the current version of React, there are both new and old context, in this case, the old version of context.

3.workInProgress.type = current.type

The fiber.type remains unchanged before and after the update, for example, div does not change to p.

4. Including SomeLane (renderLanes, updateLanes)?

Is there an update on the current fiber, and if so, is the priority of the update the same as the priority scheduled for the entire Fiber tree this time?

If the consensus indicates that there is an update on the component, you need to follow the render logic.

The optimization of bailout is more than that. If all nodes of a fiber subtree are not updated, even if all descendants of fiber follow bailout logic, there is still a cost of traversal.

Therefore, in bailout, all descendants of the fiber are checked to see if the fiber satisfies condition 4 (the check time complexity O (1)).

If all descendants of fiber do not need to update this time, bailout will directly return null. The whole subtree was skipped.

Neither bailout nor render, as if it doesn't exist. There is no change in the corresponding DOM.

The implementation of the old context API

When we got a general idea of render. With this concept, you can understand how ContextAPI is implemented and why it is refactored.

Let's first look at the implementation of the obsolete ContextAPI.

The generation process of Fiber tree is interruptible and recursive through traversal, so it is divided into two stages: recursion and recursion.

The corresponding data of Context is saved in the stack.

During the delivery phase, Context keeps getting into the stack. So Concumer can find the corresponding context value up through the Context stack.

In the return phase, Context keeps getting out of the stack.

So why was the old ContextAPI abandoned? Because he can't cooperate with performance optimization tools such as shouldComponentUpdate or Memo.

The realization of shouldComponentUpdate

To explore the deeper reasons, we need to understand the principle of shouldComponentUpdate, later referred to as SCU.

SCU is used to reduce unnecessary render, in other words: let components that are supposed to be render follow bailout logic.

Just now we introduced the conditions that bailout needs to meet. So which of these four conditions does SCU act on?

Obviously the first one: oldProps = = newProps

When using shouldComponentUpdate, the conditions for this component bailout change:

-- oldProps = = newProps

+ + SCU = false

Similarly, when using PureComponenet and React.memo, the conditions of bailout also change:

-- oldProps = = newProps

+ + shallow comparison of equality between oldProps and newsProps

Go back to the old ContextAPI.

When these performance optimization methods:

Make the component hit the bailout logic

At the same time, if the subtree of the component satisfies the condition 4 of bailout

Then the fiber subtree will not continue traversing the build.

In other words, will not experience the Context stack, off the stack.

In this case, even if the context value changes, the descendant component cannot detect it.

Implementation of the new Context API

Knowing the shortcomings of the old context ContextAPI, let's take a look at how the new API is implemented.

When passed:

Ctx = React.createContext ()

After creating an context instance, you need to provide value using Provider and subscribe to value using Consumer or useContext.

Such as:

Ctx = React.createContext (); const NumProvider = ({children}) = > {const [num, add] = useState (0); return (add (num + 1)} > add {children})}

Use:

Const Child = () = > {const {num} = useContext (Ctx); return

{num}

}

When traversing the component generates the corresponding fiber, traversing to the Ctx.Provider component, the Ctx.Provider will determine whether the context value has changed.

If the context value changes, a downward depth-first traversal of the subtree is performed within the Ctx.Provider to find the Consumer that matches the Provider.

In the above example, you will eventually find the fiber corresponding to the Child component of useContext (Ctx) and trigger an update for that fiber.

Note that the implementation here is very clever:

General updates are generated by the method that the component calls to trigger the update. For example, in the NumProvider component above, clicking button to call add triggers an update.

The essence of triggering the update is to make the component create the corresponding fiber without meeting the bailout condition 4:

! includesSomeLane (renderLanes, updateLanes)?

To enter the render logic.

Here, the context value changes in Ctx.Provider, and Ctx.Provider goes down to find the component that consumes context value, Child, and triggers an update for its fiber.

Then the corresponding fiber of Child does not satisfy condition 4.

This solves the problem of the old ContextAPI:

Since the fiber corresponding to Child does not meet condition 4, this subtree cannot meet the requirements from Ctx.Provider to Child:

!! All descendant nodes in the subtree satisfy condition 4

So even if a component enters the bailout logic in the middle of the traversal, it will not return null, that is, it will not ignore the traversal of the subtree.

Finally, the traversal goes to Child, because it does not meet condition 4, it will enter the render logic and call the corresponding function of the component.

Const Child = () = > {const {num} = useContext (Ctx); return

{num}

}

In the function call, useContext is called to find the updated context value from the Context stack and return.

This is the end of the introduction on "how to optimize React performance from Context source code". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.