Fiber architecture brief analysis

Fiber is a rewrite of React 16’s React core algorithm. Fiber will make the React rendering process asynchronous instead of synchronous.

Prior to React 16, every time we triggered a component update, React would build a new virtual DOM tree and diff with the previous virtual DOM tree to implement a directed UPDATE to the DOM. This is a recursive process. The following diagram illustrates the characteristics of this process

The recursive call stack for synchronous rendering is very deep, and the entire rendering process will start to return layer by layer only after the lowest call is returned. This long, uninterruptible update process creates a huge risk for the user experience: once synchronous rendering starts, it will hang on to the main thread until the recursion is complete. During this process, the browser can’t handle anything beyond rendering and enters a state where it can’t handle user interaction. So if the rendering time is slightly longer, the page runs the risk of stalling or even getting stuck

The Fiber architecture introduced in React 16 addresses this risk: Fiber breaks up a large update task into many smaller tasks. Each time a small task is completed, the render thread passes the main thread back to see if there is any higher-priority work to be done, making sure that other tasks don’t starve to death, thus avoiding lag caused by synchronous rendering. In this process, the rendering thread is no longer “gone forever”, but can be interrupted. This is called “asynchronous rendering”, which is executed as shown below:

An important feature of the Fiber architecture is asynchronous rendering that can be interrupted. The React 16 lifecycle is divided into render and COMMIT phases, and the COMMIT phase is subdivided into pre-commit and COMMIT phases. The life cycle covered by each phase is shown below

Let’s take a look at the characteristics of each of the three stages.

1. Render phase: Pure and without side effects, may be suspended, terminated, or restarted by React.

2. Pre-commit phase: DOM can be read.

The 3.com MIT phase: you can use DOM, run side effects, and schedule updates.

In general, the Render phase allows interruption during execution, whereas the Commit phase is always executed synchronously.

Why is it designed this way? To put it simply, the render phase is “invisible” to the user, so even interrupting and restarting the render phase will be insensitive to the user. The commit phase involves rendering the real DOM, so the process must be stabilized with synchronous rendering

With Fiber, the Render phase allows pauses, terminations, and restarts. When a task is interrupted in the middle of execution and the next time the render thread takes back control, the task is restarted in the form of “repeat the entire task” rather than “pick up where you left off”. This leads to the possibility of repeated execution of the render phase lifecycle.

Take a look at what life cycles React 16 plans to deprecate:

ComponentWillMount;

ComponentWillUpdate;

ComponentWillReceiveProps.

What these life cycles have in common is that they are all render phases, they can be repeated, and because these apis have been abused over the years, there is a significant risk of repeated execution.

Overall, the main motivation for the React 16 lifecycle was to work with the asynchronous rendering mechanism brought about by the Fiber architecture. During this process, the React team kept improving and implemented mandatory best practices for the chronically abused parts of the life cycle. All of this work is done to ensure data and view security in Fiber and to ensure that the behavior of the lifecycle method is pure, controllable, and predictable.