Shulou(Shulou.com)06/03 Report--

This article focuses on "how to understand the queue-jumping mechanism of high-priority tasks in React". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the queue-jumping mechanism of high-priority tasks in React.

Click to enter the React source code debugging warehouse.

In the concurrent mode of React, during the execution of a low priority task, once a higher priority task comes in, the low priority task will be cancelled and the high priority task will be executed first. When the high-priority task is done, the low-priority task will be redone.

Let's use a specific example to understand the queue jumping of high-priority tasks.

If you enter the page with a state of 0, you will call setState to add state to 1, which is a low priority task. React begins to update, and when this low priority task is not completed, the simulation button is clicked, state plus 2, which is a high priority task. As you can see, the number on the page changes from 0-> 2-> 3 instead of 0-> 1-> 3. This means that when the low priority task (plus 1) is in progress, the high priority task comes in, and it sets the state to 2. Due to the queue jumping of high priority tasks, the low priority task with state set to 1 is cancelled and the high priority task is done first, so the number is changed from 0 to 2. When the high priority task is completed, the low priority task is redone, so the state is added from 2 to 3.

The phenomena are as follows:

Using the performance analysis tool of chrome to capture the update process, you can clearly see the process of priority queue jumping.

I have saved the complete profile file, which can be loaded into chrome for detailed view: high priority queue jumping. Json.

You can take another look at the information of the two task priorities in the scheduling process.

Click to view the high priority queue jumping sample code file.

Click to view the low priority task Hunger sample code file.

Next, we will start from setState to explore the nature of this queue-jumping behavior, which involves the generation of update objects, initiation and scheduling, work cycle, high-priority task queue jumping, update object processing, low-priority task redoing and so on.

Generate updates

When setState is called, it means that the fiber node corresponding to the component produces an update. SetState actually generates a update object and calls enqueueSetState to connect the update object to the updateQueue list of the fiber node.

Component.prototype.setState = function (partialState, callback) {this.updater.enqueueSetState (this, partialState, callback, 'setState');}

The responsibility of enqueueSetState is to create a update object, queue it into the update linked list (updateQueue) of the fiber node, and then initiate a schedule.

EnqueueSetState (inst, payload, callback) {/ / gets the fiber node that currently triggers the update. Inst is the component instance const fiber = getInstance (inst); / / eventTime is the current timestamp triggering the update const eventTime = requestEventTime (); const suspenseConfig = requestCurrentSuspenseConfig (); / / get the priority of this update const lane = requestUpdateLane (fiber, suspenseConfig); / / create update object const update = createUpdate (eventTime, lane, suspenseConfig) / / payload is an argument to setState, a callback function, or the form of an object. / / process update.payload = payload; / / put update into fiber's updateQueue enqueueUpdate (fiber, update) when processing updates; / / start scheduling scheduleUpdateOnFiber (fiber, lane, eventTime);}

Sort out the specific things you do in enqueueSetState:

Find fiber.

First get the fiber node corresponding to the component that produces the update, because the resulting update object needs to be placed on the updateQueue of the fiber node. Then get the time when the current update is generated, which is related to the updated hunger problem, which we will not consider for a while, and the next step of suspenseConfig can be ignored.

Calculate priority

After that, it is more important to calculate the priority lane of the current update:

Const lane = requestUpdateLane (fiber, suspenseConfig)

When calculating this priority, how do you decide what to calculate based on? It also starts with the synthetic event of React.

When the event is triggered, the composite event mechanism calls the runWithPriority function in scheduler to dispatch the real event flow according to the event priority corresponding to the interactive event. RunWithPriority converts the event priority to the priority within the scheduler and records it. When requestUpdateLane is called to calculate lane, it will get the priority in scheduler as the basis for lane calculation.

The source code for this part is here.

Create a update object and join the updateQueue

Based on lane and eventTime and suspenseConfig, create a update object with the following structure:

Const update: Update = {eventTime, lane, suspenseConfig, tag: UpdateState, payload: null, callback: null, next: null,}

EventTime: the time when the update was generated

Lane: indicates priority

SuspenseConfig: task suspension related

Tag: indicates the type of update (UpdateState,ReplaceState,ForceUpdate,CaptureUpdate)

Payload: update the status carried.

In class components, there are two possibilities, object ({}), and function ((prevState, nextProps): newState = > {})

In the root component, React.element, that is, the first parameter of ReactDOM.render

Callback: can be understood as a callback of setState

Next: a pointer to the next update

The next step is to call the entry function of React task execution: scheduleUpdateOnFiber to schedule and execute the update task.

Now we know that there will be a updateQueue on the fiber node that produces the update, which contains the update that was just generated. Now it's time to enter the scheduleUpdateOnFiber and start the real scheduling process. The task of building the workInProgress tree by invoking the scheduleUpdateOnFiber,render phase is scheduled and executed, and the updateQueue on the fiber is processed during this process.

Dispatching preparation

The update entry of React is scheduleUpdateOnFiber, which distinguishes the lane of update and separates synchronous updates from asynchronous updates, allowing them to enter their respective processes. But before that, it will do a few more important tasks:

Check for infinite updates, such as calling setState in the render function.

Starting from the node that generated the update, it loops up to root in order to collect the fiber.lanes all the way up to the childLanes of the parent node. ChildLanes is the key to identifying whether the fiber subtree needs to be updated.

Mark the update on root, that is, put the lane of update into root.pendingLanes, and the priority benchmark for each rendering: renderLanes is taken from the most urgent part of root.pendingLanes, lanes.

These three steps can be seen as preparations for the implementation of the update.

The first can prevent the dead loop from getting stuck.

Second, if the fiber.lanes is not empty, the fiber node is updated, and fiber.childLanes is an important basis for judging whether the current subtree has an update. If there is an update, continue to build down, otherwise the existing fiber tree will not be reused directly, and the fiber nodes that do not need to be updated can be shielded.

The third is to add the lane of the current update object to the root.pendingLanes to ensure that when you really start the update task, you will get the lane of update, which will be used as the rendering priority (renderLanes) for this update.

In fact, the renderLanes obtained during the update does not necessarily contain the lane of the update object, because it is possible that it is just a lower priority update, and there may be a high priority update before it.

After combing through the general logic of scheduleUpdateOnFiber, let's take a look at its source code:

Export function scheduleUpdateOnFiber (fiber: Fiber, lane: Lane, eventTime: number,) {/ / the first step is to check whether there is an infinite update checkForNestedUpdates ();. / / the second step is to collect fiber.childLanes const root = markUpdateLaneFromFiberToRoot (fiber, lane) upwards; and / / the third step is to mark the update on root and put update's lane into root.pendingLanes markRootUpdated (root, lane, eventTime). ... / get the corresponding React priority const priorityLevel = getCurrentPriorityLevel () according to the priority of Scheduler. If (lane = SyncLane) {/ / this update is synchronized, for example, the traditional synchronous rendering mode if ((executionContext & LegacyUnbatchedContext)! = = NoContext & & (executionContext & (RenderContext | CommitContext)) = NoContext) {/ / if this update is synchronized and has not been rendered yet, it means that the main thread is idle There is no React / update task in progress, so call performSyncWorkOnRoot to start the synchronization task. PerformSyncWorkOnRoot (root);} else {/ / if this update is synchronized, but there is currently a React update task in progress, / / and because it cannot be interrupted, the purpose of calling ensureRootIsScheduled / / is to reuse the task that is already being updated, so that the existing task / / ensureRootIsScheduled this update by the way (root, eventTime) ...}} else {... / / Schedule other updates after in case the callback is sync. / / if the update is asynchronous, call ensureRootIsScheduled to enter the asynchronous scheduling ensureRootIsScheduled (root, eventTime); schedulePendingInteractions (root, lane);}.}

The complete source code of scheduleUpdateOnFiber is here, here is the second step: markUpdateLaneFromFiberToRoot and the third step: the complete source code of markRootUpdated, I have made comments.

After the previous preparation, scheduleUpdateOnFiber will finally call ensureRootIsScheduled to get the React task scheduled, which is a very important function related to the convergence of equal or lower tasks,

Queue jumping of high priority tasks and task hunger, which are explained in more detail below.

Start scheduling

Before we begin to talk about ensureRootIsScheduled, it is necessary to understand the nature of React's update task.

The nature of React tasks

The generation of a update will eventually enable React to build a new fiber tree in memory based on the existing fiber tree, and the calculation of the new state, diff operations, and some lifecycle calls will take place during this construction process. The overall construction work is called the render phase, and the render phase as a whole is a complete React update task. The update task can be seen as executing a function, which is performConcurrentWorkOnRoot in concurrent mode. The scheduling of update tasks can be seen as a function that scheduler arranges when it is executed according to task priority.

Scheduler scheduling and React scheduling are two completely different concepts. React scheduling is a scheduling mode to coordinate tasks into which Scheduler, its scheduling does not involve task execution, while Scheduler is the real core of the scheduling mechanism, which actually executes tasks. Without it, React tasks can not be executed no matter how important they are. I hope readers can distinguish between these two concepts.

When a task is scheduled, scheduler generates a task object (task), which is structured as follows and does not need to care about the meaning of fields other than callback for the time being.

Var newTask = {id: taskIdCounter++, / / task function, that is, performConcurrentWorkOnRoot callback, / / task scheduling priority, transformed from the task priority to be discussed to priorityLevel, / / the point in time at which the task begins to execute, / / the task expiration time expirationTime, / / the task queue sorted in the small top stack according to sortIndex:-1,}

Whenever such a task is generated, it is mounted on the callbackNode attribute of the root node to indicate that a task has been scheduled and that the task priority is stored on the callbackPriority of root

Indicates that if a new task comes in, its task priority must be compared with the priority (root.callbackPriority) of the existing task to determine whether it is necessary to cancel the existing task.

Therefore, when scheduling tasks, task priority is an indispensable important role.

Task priority

The task itself is generated by updates, so the task priority is essentially related to the priority of the update, that is, update.lane (only relevant, not necessarily from it). The resulting task priority belongs to lanePriority, which is not the lane of update, and is different from the scheduling priority within scheduler. The priority transformation relationship in React can be seen in an article I have summarized: priority in React. Here we only discuss the generation process of task priority.

As mentioned at the end of the scheduling preparation, the update.lane is put into the root.pendingLanes, and then the lanes with the highest priority in the root.pendingLanes is taken as the renderLanes. The generation of task priority occurs in the stage of calculating renderLanes, and the task priority is actually the lanePriority corresponding to renderLanes. Because renderLanes is the priority benchmark for this update, its corresponding lanePriority is taken as a task priority to measure the priority weight of this update task.

Root.pendingLanes, which contains the lane of all pending update in the current fiber tree.

There are three types of task priorities:

Synchronization priority: the priority held by update tasks generated by React's traditional synchronous rendering mode

Synchronous batch priority: synchronous mode to concurrent mode transition mode: priority held by update tasks generated by blocking mode (introduction)

Priority in concurrent mode: priority held by updates generated by concurrent mode

The two lane on the far right are synchronization priority and synchronization batch priority, respectively, and almost all of the remaining lane on the left are related to concurrent mode.

Export const SyncLane: Lane = / * * / 0b000000000000000000000000000000000000000000000000001; export const SyncBatchedLane: Lane = / * * / 0b00000000000000000010; lanes:/* * / 0b1111111111111111111111111111100 in concurrent mode

The function for calculating renderLanes is getNextLanes, and the function for generating task priority is getHighestPriorityLanes.

The task priority determines how the task is scheduled in React, and the task scheduling priority is converted from the task priority to the task scheduling priority (priorityLevel in scheduler's task structure given above)

Decides when Scheduler will deal with the task.

Task scheduling Coordination-ensureRootIsScheduled

So far, we have understood the nature of tasks and task priorities, and let's formally enter the task scheduling process. The scheduling of tasks on the React side is essentially based on task priority to operate multiple or single tasks.

In the case of multiple tasks, compared to the new task, existing tasks will be reused or cancelled, in the case of a single task, or synchronized, or asynchronously, or batch synchronized (no concern for the time being)

This kind of behavior can be regarded as a kind of task scheduling coordination mechanism, which is realized through ensureRootIsScheduled.

Let's take a look at what the ensureRootIsScheduled function does. First, prepare the lanes and task priority needed for this task scheduling and coordination, and then determine whether scheduling is really needed.

Get root.callbackNode, that is, old task

Check whether the task is expired, and put the expired task into the root.expiredLanes, so that the expired task can enter the schedule with synchronization priority (execute immediately)

Get the renderLanes (priority is obtained from root.expiredLanes). If the renderLanes is empty, it means no scheduling is required, and you can simply return it.

Get this task, the priority of the new task: newCallbackPriority

The next step is the process of coordinating task scheduling:

First determine whether it is necessary to initiate a new schedule by comparing the priority of the new task with that of the old task:

Equal, it means that there is no need to initiate a schedule again, just reuse the old task and let the old task do the new task while dealing with the update.

If it is not equal, it means that the priority of the new task must be higher than that of the old task. In this case, the high-priority task will jump the queue and the old task needs to be cancelled.

Really initiate scheduling, depending on the task priority of the new task:

Synchronization priority: call scheduleSyncCallback to execute tasks synchronously.

Synchronous batch execution: call scheduleCallback to add tasks to the schedule at the priority of immediate execution.

Priority belonging to concurrent mode: call scheduleCallback to add the task to the schedule with the new task priority obtained above.

Here are two points to make:

1. Why is it that if the priorities of the old and new tasks are not equal, then the priority of the new task must be higher than that of the old one?

This is because every time the scheduling goes to get the task priority, it only gets the priority corresponding to the most urgent part of the root.pendingLanes lanes, and the priority corresponding to the lane held by the low-priority update can not be obtained. In this way, multiple updates from the same event can be converged into one task to execute, implying that multiple updates triggered by the same event have the same priority, and there is no need to initiate multiple task scheduling. For example, setState is called multiple times in an event:

Class Demo extends React.Component {state = {count: 0} onClick = () = > {this.setState ({count: 1}) this.setState ({count: 2})} render () {return {this.state.count}

2 is directly displayed on the page. Although the onClick event calls setState twice, it only causes one schedule. The schedule that sets count to 2 is because the priority is the same as that of the task with count set to 1.

So instead of initiating the scheduling again, we reuse the existing tasks. This is a change to multiple setState optimizations implemented by React17, which was previously implemented through a mechanism like batchingUpdate.

1. What are the differences in the scheduling modes of the three task priorities, and what is the behavior?

Synchronization priority: traditional React synchronous rendering mode and scheduling of expired tasks. The task function performSyncWorkOnRoot is added to React's own synchronization queue (syncQueue) through the scheduleSyncCallback function provided by React, and then the function of looping syncQueue is added to scheduler with the priority of ImmediateSchedulerPriority, so that the task is executed in the next event loop. However, due to the control of React, the time slices in this mode will be checked after all the tasks have been executed, showing that there is no time slice.

Synchronous batch execution: the blocking mode of transition from synchronous rendering mode to concurrent rendering mode adds the task function performSyncWorkOnRoot to scheduler with the priority of ImmediateSchedulerPriority, which also allows the task to be executed in the next event loop without the performance of a time slice.

Priority belonging to concurrent mode: add the task function performConcurrentWorkOnRoot to the scheduler with the priority of the task, and the internal scheduler will control the ordering of the task in the scheduler internal task queue through this priority, thus determining the appropriate execution of the task, and the real execution of the task will have the performance of time slices, which can give full play to the real power of scheduler asynchronous interruptible scheduling.

It is important to note that the priority used to compare old and new tasks is not the same as the priority passed in here to add the task to the scheduler, which can be transformed from the former through lanePriorityToSchedulerPriority.

After the above analysis, I believe you have a clear understanding of the operating mechanism of ensureRootIsScheduled. Now let's take a look at its implementation:

Function ensureRootIsScheduled (root: FiberRoot, currentTime: number) {/ / get the old task const existingCallbackNode = root.callbackNode; / / record the expiration time of the task, check whether there is an expired task, and put it in root.expiredLanes immediately, / / so that the task can be dispatched immediately in synchronous mode markStarvedLanesAsExpired (root, currentTime); / / get renderLanes const nextLanes = getNextLanes (root, root = workInProgressRoot? WorkInProgressRootRenderLanes: NoLanes,); / / get the task priority corresponding to renderLanes const newCallbackPriority = returnNextLanesPriority (); if (nextLanes = NoLanes) {/ / if the rendering priority is empty, there is no need to schedule if (existingCallbackNode! = = null) {cancelCallback (existingCallbackNode); root.callbackNode = null; root.callbackPriority = NoLanePriority;} return } / / if there are old tasks, see if you can reuse if (existingCallbackNode! = = null) {/ / get the priority of the old tasks const existingCallbackPriority = root.callbackPriority; / / if the old and new tasks have the same priority, there is no need to schedule if (existingCallbackPriority = newCallbackPriority) {return } / / the execution of the code here indicates that the priority of the new task is higher than that of the old task / / cancel the old task to achieve high-priority task queue cancelCallback (existingCallbackNode);} / / schedule a new task let newCallbackNode If (newCallbackPriority = SyncLanePriority) {/ / if the priority of the new task is synchronous priority, then synchronous scheduling, traditional synchronous rendering and expired tasks will go here newCallbackNode = scheduleSyncCallback (performSyncWorkOnRoot.bind (null, root),) } else if (newCallbackPriority = SyncBatchedLanePriority) {/ / transition mode from synchronous mode to concurrent mode: blocking mode will go here newCallbackNode = scheduleCallback (ImmediateSchedulerPriority, performSyncWorkOnRoot.bind (null, root),);} else {/ / concurrent mode rendering will go here / / get Scheduler scheduling priority const schedulerPriorityLevel = lanePriorityToSchedulerPriority (newCallbackPriority,) according to task priority / / after calculating the scheduling priority, start letting Scheduler schedule the update task of React newCallbackNode = scheduleCallback (schedulerPriorityLevel, performConcurrentWorkOnRoot.bind (null, root),);} / / update the task priority and task on root so that you can get root.callbackPriority = newCallbackPriority; root.callbackNode = newCallbackNode;} the next time you initiate the scheduling

EnsureRootIsScheduled actually integrates the key logic of high-priority task queue jumping and task hunger at the task scheduling level, which is only a macro-level decision, and the reason behind the decision is that React handles updates.

For the trade-off of update with different priorities and the marking of root.pendingLanes, this requires us to sink into the process of performing the update task.

Working with updates

Once an update is generated, the update object is put into the updateQueue and mounted on the fiber node. When you build a fiber tree, you take renderLanes to deal with updateQueue, and in the beginWork phase, for class components

The processUpdateQueue function is called to process each update object on the linked list one by one, calculating the new state. Once the priority held by the update is not enough, the processing of the update is skipped, and the lane of the skipped update is put into the fiber.lanes so that it can be collected in the completeWork phase.

The process of cycling updateQueue to calculate state is actually more complex, because low-priority update will be skipped and redone, so this involves the problem of final state unification. The principle of this process is interpreted in my article: pick the principle of React computing state, and only focus on the parts related to priority in this article.

The part about priority is easy to understand, which is to only deal with update with sufficient priority, skip those update with insufficient priority, and put the lane of these update into fiber.lanes. Let's take a direct look at the implementation:

Function processUpdateQueue (workInProgress: Fiber, props: any, instance: any, renderLanes: Lanes,): void {. If (firstBaseUpdate! = = null) {let update = firstBaseUpdate; do {const updateupdateLane = update.lane The meaning of the / / isSubsetOfLanes function is to determine whether the current update priority (updateLane) / / is not in the rendering priority (renderLanes). If it is not there, it means that the priority is insufficient if (! isSubsetOfLanes (renderLanes, updateLane)) {. / * newLanes will be assigned to the workInProgress.lanes at last. And it will eventually * be collected into root.pendingLanes. * * when updating again, the priority level (renderLanes) that should be updated this time is found from the pendingLanes on root. RenderLanes contains the priority skipped this time. Enter again, * the priority of processUpdateQueue wip meets the requirements and is updated, and the low priority task * is therefore redone * / newLanes = mergeLanes (newLanes, updateLane). } else {/ / priority is sufficient to calculate state.}} while (true); / / assign newLanes to workInProgress.lanes, / / put the lane of the skipped update into fiber.lanes workInProgress.lanes = newLanes;}}

Only dealing with update with sufficient priority is the most essential reason for high-priority tasks to be executed. After a cycle of updateQueue, the lane of those skipped update is put into fiber.lanes again. Now, just put it into root.pendingLanes, it can show that there are still tasks unprocessed after this round of updates, thus realizing that low-priority tasks are rescheduled. So the next process is the completion phase of the fiber node: the completeWork phase to collect the lanes.

Collect unprocessed lane

During completeUnitOfWork, fiber.lanes and childLanes are collected layer by layer into the childLanes of the parent fiber. This process occurs in the resetChildLanes called in the completeUnitOfWork function, which loops the child tree of the fiber node and collects the lanes and childLanes from the child node and its sibling nodes to the childLanes on the fiber node that is currently in the complete phase.

Assuming that both the and components in layer 3 have update skipped because of insufficient priority, resetChildLanes will be called when their parent div fiber node completeUnitOfWork

Collect their lanes into div fiber.childLanes, and finally collect all lanes to root.pendingLanes.

Root (pendingLanes: 0b01110) | 1 App | | 2 compeleteUnitOfWork- > div (childLanes: 0b01110) / / 3->-> p (lanes: 0b00010) (lanes: 0b00100) (childLanes: 0b01000) / / 4 p ul / / li-> li

With each upward loop, resetChildLanes is called to collect the fiber.childLanes layer by layer.

Function completeUnitOfWork (unitOfWork: Fiber): void {/ / the fiber node that has finished the beginWork phase is called completedWork let completedWork = unitOfWork Do {/ / the process of cycling up to root. / / there is no Incomplete on the .flags of the fiber node, indicating that the work has been completed normally. If ((completedWork.flags & Incomplete) = NoFlags) {. / / call resetChildLanes to collect lanes resetChildLanes (completedWork) ...} else {/ *... * /}.} while (completedWork! = = null);...}

ResetChildLanes collects only the lanes and childLanes of the child and sibling nodes of the fiber node that is currently complete:

Function resetChildLanes (completedWork: Fiber) {... Let newChildLanes = NoLanes; if (enableProfilerTimer & & (completedWork.mode & ProfileMode)! = = NoMode) {/ / profile related, no need to pay attention to} else {/ / loop child nodes and sibling nodes, collect lanes let child = completedWork.child While (child! = = null) {/ / Collection process newChildLanes = mergeLanes (newChildLanes, mergeLanes (child.lanes, child.childLanes),); childchild = child.sibling;}} / / put the collected lanes into the childLanes of the fiber node completedWork.childLanes = newChildLanes;}

Finally, the process of putting these collected childLanes into root.pendingLanes takes place in the commit phase of this update, because the rendering priority of the render phase comes from root.pendingLanes and cannot be modified at will. So you have to modify it in the commit phase after the render phase. Let's take a look at the implementation of this process in commitRootImpl:

Function commitRootImpl (root, renderPriorityLevel) {/ / assigns the collected childLanes, together with root's own lanes, to remainingLanes let remainingLanes = mergeLanes (finishedWork.lanes, finishedWork.childLanes); / / markRootFinished assigns remainingLanes to remainingLanes markRootFinished (root, remainingLanes);.}

Rescheduling

At this point, we re-collect the lane of low-priority tasks into root.pendingLanes, and we only need to initiate a schedule again, which can be achieved by calling ensureRootIsScheduled again in the commit phase, so that we will go through the scheduling process again, and low-priority tasks will be executed.

Function commitRootImpl (root, renderPriorityLevel) {/ / assigns the collected childLanes, together with root's own lanes, to remainingLanes let remainingLanes = mergeLanes (finishedWork.lanes, finishedWork.childLanes); / / remainingLanes is assigned to remainingLanes markRootFinished (root, remainingLanes) in markRootFinished; / / this ensureRootIsScheduled / / is called every time all updates are completed to ensure that any pendingLanes on root can be processed ensureRootIsScheduled (root, now ());}

Summary

There are four key points in the whole process of high-priority task jumping and low-priority task redoing:

EnsureRootIsScheduled cancels existing low-priority update tasks, reschedules a task to do high-priority updates, and takes lanes, the most important part of root.pendingLanes, as rendering priority

Skip the low-priority update in updateQueue and mark its lane into fiber.lanes when performing the update task.

The complete phase of the fiber node collects the fiber.lanes to the childLanes of the parent fiber, all the way to root.

The commit phase assigns all root.childLanes to root.pendingLanes along with root.lanes.

Rescheduling at the end of the commit phase.

The whole process always focuses on high-priority tasks and takes into account the overall situation, which can best reflect React's determination to improve the user experience.

At this point, I believe you have a deeper understanding of "how to understand the queue-jumping mechanism of high-priority tasks in React". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.