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

This article is about what fiber is used for in react. Xiaobian thinks it is quite practical, so share it with everyone for reference. Let's follow Xiaobian and have a look.

Fiber is React's new scheduling algorithm, a reimplementation of the core algorithm. React Fiber fragments the update process, returning control to React's task coordination module at the end of each update process to see if there are other urgent tasks to do, and if there are urgent tasks, do urgent tasks.

This tutorial will operate on Windows 7, React17.0.1, Dell G3 PC.

Fiber was introduced after react16, and scheduling, coordination, diff algorithms, and rendering at the entire architecture level are closely related to fiber.

What is React Fiber?

react When rendering components, the entire process from setState to rendering is synchronized ("in one go"). If the component to be rendered is large, js execution will occupy the main thread for a long time, which will lead to poor page responsiveness, making react less effective in animation, gestures and other applications.

To solve this problem, the react team spent two years rewriting the core algorithm in react-reconciliation. This new feature was released in v16. In order to distinguish between the previous and the subsequent reconciler, the previous reconciler is usually called a stack reconciler, and the rewritten one is called a fiber reconciler.

The official one-sentence explanation is that "React Fiber is a re-implementation of the core algorithm."

Fiber improves responsiveness and performance for complex React applications. Fiber is a new reconciliation algorithm.

React Fiber fragments the update process, returning control to React's task coordination module at the end of each update process to see if there are other urgent tasks to do, and if there are no urgent tasks, continue to update, and if there are urgent tasks, do urgent tasks.

react When rendering components, the entire process from setState to rendering is synchronized ("in one go"). If the component to be rendered is large, js execution will occupy the main thread for a long time, which will lead to poor page responsiveness, making react less effective in animation, gestures and other applications.

To solve this problem, the react team spent two years rewriting the core algorithm in react-reconciliation. This new feature was released in v16. In order to distinguish between the previous and the subsequent reconciler, the previous reconciler is usually called a stack reconciler, and the rewritten one is called a fiber reconciler.

Caton causes

Stack deconciler's workflow is much like function invocation. A subcomponent within a parent component can be likened to recursion of a function (which is why it is called a stack deconciler). Immediately after setState, react starts the reconciliation process, traversing from the parent node (Virtual DOM) to find the difference. After traversing all the Virtual DOM, the reconciler can give information about the current need to modify the real DOM, and pass it to the renderer for rendering, and then the updated content will be displayed on the screen. For particularly large vDOM trees, the reconciliation process can be very long (x00ms), during which the main thread is occupied by js, so any interaction, layout, rendering will stop, giving the user the feeling that the page is stuck.

Scheduler

Scheduling is a process of fiber reconciliation that determines what should be done at what time. The procedure shows that in stack reconciler, reconciliation is "in one go", which is fine for functions because we only want the result of the function, but for UI we also need to consider the following:

Not all state updates need to be displayed immediately, such as off-screen updates

Not all updates have the same priority, e.g. responses to user input have a higher priority than responses to requests to fill content

Ideally, for some high-priority operations, it should be able to interrupt the execution of low-priority operations, such as user input, a comment on the page is still in reconciliation, should respond to user input first.

So ideally the reconciliation process should be as shown in the figure below, doing only one small task at a time, being able to "catch your breath" after doing it, returning to the main thread to see if there are any higher priority tasks to be processed, and if there are higher priority tasks to be processed first, then continue to execute (cooperative scheduling).

task splitting fiber-tree & fiber

Let's see how react works under stack-reconciler. Create (or update) elements in the code, react will create (or update) Virtual DOM based on these elements, and then react will modify the real DOM based on the difference between the virtual DOM before and after the update. Note that under stack reconciler, DOM updates are synchronized, that is, during the comparison process of virtual DOM, if an instance is found to have an update, DOM operations will be performed immediately.

With fiber-conciler, operations can be broken up into small parts, so synchronizing DOM operations may cause the fiber-tree to be out of sync with the actual DOM. For each node, it not only stores the basic information of the corresponding element, but also stores some information for task scheduling. Therefore, fiber is just an object that represents the smallest unit of work that can be split in the reconciliation phase, corresponding to the reaction instance in the above figure. Manage Instance's own properties through stateNode attributes. The next unit of work of the current unit of work is characterized by child and sibling. Return indicates the target to be merged after the processing is completed, usually pointing to the parent node. The whole structure is a linked list tree. After each unit of work (fiber) is completed, it will check whether it still has the main thread time slice, if there is one, continue to the next, if not, process other high-priority transactions first, and wait for the main thread to idle and continue execution.

fiber { stateNode: {}, child: {}, return: {}, sibling: {},} copy code for example

The current page contains a list that renders a button and a set of Items, each of which contains a div containing numbers. By clicking the button, you can square all the numbers in the list. There is also a button that can be clicked to adjust the font size.

When the page is rendered, a fiber-tree is initialized. Initializing a fiber-tree is no different from initializing a Virtual DOM tree, so I won't go into detail here.

React also maintains a workInProgressTree. workInProgressTree is used to compute updates and complete the reconciliation process.

After the user clicks the square button, setState is called using the squared list of elements, and react will send the current update to the update queue corresponding to the list component. But react doesn't immediately compare and modify DOM operations. It's left to the scheduler.

The scheduler handles the update based on the current usage of the main thread. To implement this feature, the requestIdelCallback API is used. For browsers that do not support this API, react adds pollyfill.

Generally speaking, client threads are divided into frames when executing tasks. Most device control does not affect user experience in frames 30-60. Between two execution frames, the main thread usually has a short idle time. requestIdleCallback can call Idle Callback during this Idle Period to execute some tasks.

Low-priority tasks are handled by requestIdleCallback;

High-priority tasks, such as animation related tasks, are handled by requestAnimationFrame;

requestIdleCallback can call idle callback in multiple idle periods to execute tasks;

requestIdleCallback method provides deadline, i.e. task execution time limit, to split tasks, avoid long execution time, block UI rendering and cause frame drop;

Once the reconciliation process gets the time slice, it begins to enter the work loop. The work loop mechanism allows react to switch between a compute state and a wait state. To do this, for each loop, two things need to be tracked: the next unit of work (the next fiber to be processed), and the time currently available to the main thread. The first loop, the next pending unit is the root node.

Because the update queue on the root node is empty, copy the root node directly from the fiber-tree to workInProgressTree. The root node contains pointers to child nodes (List).

The root node does not have any update operations, and according to its child pointer, the List node and its corresponding update queue are copied to workinprogress. After List is inserted, it returns to its parent node, marking the completion of processing of the root node.

After root node processing is complete, react checks to see if the time slice has run out. If not, start processing the next Node List according to the information of the next work unit it saves.

Next, enter the work loop of processing List, which contains updates, so react will call updater funciton passed in setState to get the latest state value, which should be [1,4,9]. Usually we now pass an object in the call to setState, but when using fiber conciler, we must pass a function whose return value is the state to be updated. React has supported this script since very early versions, but it is usually not used. In later versions of react, the directly passed object may be deprecated.

setState({}, callback); // stack concilersetState(() => { return {}, callback); // fiber concilerCopy code

After getting the latest state value, react updates the state and props values of List, then calls render, and gets a set of elements generated from the updated list value. React determines whether a fiber is reusable based on the type of elements generated. For the current case, the newly generated elements have the same type (Button and Item), so react copies the fibers corresponding to these elements directly from the fiber-tree into workInProgress. And label List because it's a node that needs updating.

When the List node is finished, react will still check whether the current time slice is sufficient. If enough is enough, proceed to the next button. When adding this, the user clicks the button to enlarge the font. This operation of enlarging fonts is purely implemented by js and has nothing to do with react. But the action doesn't take effect immediately, because the time slice of react hasn't run out yet, so you still have to continue processing button.

button does not have any child nodes, so you can return at this point and mark button processing is complete. If the button has changed, you need to tag it, but the current situation does not, just mark it complete.

As usual, after processing a node, we should first see if there is enough time. Note that the font enlargement operation is already waiting to release the main thread.

Next, deal with the first item. The shouldComponentUpdate hook allows you to determine whether the props you pass in need of change. For the first Item, before and after the change is 1, so it will not change, shouldComponentUpdate returns false, copy div, processing is complete, check the time, if there is still time to enter the second Item.

The second Item shouldComponentUpdate returns true, so it needs to be tagged, the flag needs to be updated, copy div, call render, and update the contents of div from 2 to 4, because div has updates, so mark div. Processing of current node completed.

In this case, div is already a leaf node and has no siblings, and its value has been updated. In this case, you need to merge the effects of this node change into the parent node. React maintains a list of all elements that produce effects.

After merging, return to parent node Item, parent node marks completion.

The next unit of work is Item, check the time before entering Item. But time ran out at this point. React must swap the main thread and tell it to allocate time later to complete the rest of the operation.

The main thread then enlarges the font. After the completion of the implementation of react next operation, with an Item processing flow is almost the same, after the completion of the entire fiber-tree and workInProgress as follows:

When completed, Item returns to List and merges effect, which now looks like this:

At this point List returns to the root node and merges effect, all nodes can be marked complete. At this point react marks workInProgress as pendingCommit. It means you can enter the commit phase.

At this point, what you have to do is to check if there is enough time. If there is no time, you will wait until the time to commit the changes to DOM. After entering phase 2, reacDOM updates DOM based on the effect-list calculated in phase 1.

After updating the DOM, workInProgress is completely consistent with the DOM. In order to keep the current fiber-tree and DOM consistent, react swaps the current and workinProgress pointers.

In fact, react spends most of its time maintaining Double-buffering. This reduces the time it takes to allocate memory and garbage on the next update. When commit is complete, execute the componentDidMount function.

summary

By breaking the reconciliation process down into smaller units of work, you can make pages more responsive to browser events. However, another problem that has not been solved is that if the current react rendering takes a long time, it will still block the subsequent react rendering. This is why fiber reconciler adds priority policies.

Thank you for reading! About "what is the use of fiber in react" this article is shared here, I hope the above content can be of some help to everyone, so that everyone can learn more knowledge, if you think the article is good, you can share it to let more people see it!

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.