Front knowledge

Single-threaded JavaScript versus multi-threaded browsers

JavaScript is single-threaded and browsers are multi-threaded. For multi-threaded browsers, in addition to dealing with JavaScript threads, you also need to deal with a variety of task threads including event systems, timers/delayers, network requests, and so on. This includes the UI rendering thread that handles the DOM. JavaScript threads can manipulate the DOM.

If the rendering thread and the JavaScript thread are working at the same time, the rendering result is necessarily unpredictable, and the JavaScript thread and the rendering thread must be mutually exclusive: the two threads cannot be interspersed and must be serial. While one thread is executing, the other thread can only suspend and wait.

A similar feature is Event threads, where the browser’s event-loop mechanism determines that Event tasks are maintained by an asynchronous queue. When the event is triggered, the corresponding task will not be executed immediately, but the event thread adds it to the end of the task queue, waiting for the JavaScript synchronization code to complete, and then execute the queue in the idle time.

If the JavaScript thread is tied to the main thread for a long time, then the render layer update has to wait for a long time, and the interface is not updated for a long time, resulting in a user experience called “stutter”.

In React 15 and its earlier versions, the data structure carrier of the virtual DOM tree is the “tree” in computer science. The traversal idea of the Diff algorithm is the depth-first traversal process of the tree.

The lethality of this process is that it is synchronous and cannot be interrupted. When dealing with a relatively complex and large virtual DOM tree, the Stack Reconciler takes a long time to reconcile, which means that JavaScript threads can occupy the main thread for a long time, leading to the kind of stalling/gridlock we described above, and long periods of unresponsive interactions.

Fiber ideas

The word Fiber translates to “silk, Fiber,” and Fiber is a process that is even thinner than thread. The advent of fibers is intended to provide finer control over the rendering process.

Fiber is a polysemy.

  • From an architectural perspective,FiberIs theReactRewrite the core algorithm (harmonic process);
  • From a coding point of view,Fiber 是 ReactAn internally defined data structure that isFiberThe unit of nodes in a tree, which is thetaReact 16The “virtual DOM” under the new architecture;
  • From a workflow perspective,FiberThe node holds the state and side effects that the component needs to update, oneFiberIt also corresponds to a unit of work.

The purpose of the Fiber architecture, according to React officials, is to enable “incremental rendering.” Incremental rendering, in layman’s terms, is the splitting of a rendering task into multiple rendering tasks and then spreading them over multiple frames.

However, strictly speaking, incremental rendering is actually just a means to achieve the purpose of incremental rendering in order to achieve interruptible and recoverable tasks, and give different tasks different priorities, and ultimately achieve a smoother user experience.

Fiber Architecture core: interruptible, Recoverable, and Priority

inReact16Before,ReactThe render and update phases of the web browser rely on a two-tier architecture as shown below:

The Reconciler layer is responsible for comparing the changes between the old and new virtual DOM, and the Renderer layer is responsible for applying the changes to the view. The process from Reconciler to Renderer is strictly synchronized.

And in the React 16In order to achieve “interruptibility” and “priority”, the two-tier architecture becomes a three-tier architecture as shown in the figure below:

The additional layer of architecture is called a “Scheduler,” which schedules the priority of updates.

In this architectural pattern, the updated processing workflow looks like this:

  • First, each update task is assigned a priority. When the update task arrives at the scheduler, the higher-priority update task (denoted as A) is scheduled more quicklyReconcilerLayer;
  • At this time, if A new update task (denoted as B) arrives at the scheduler, the scheduler will check its priority. If it finds that the priority of B is higher than that of the current task A, the current task isReconcilerLayer A’s task will be interrupted, and the scheduler will push task B inReconcilerLayer.
  • When task B finishes rendering, A new round of scheduling starts, and the previously interrupted task A will be pushed back inReconcilerLayer, continues its rendering journey, which is called “recoverable”.

That’s how architecture deals with the core concepts of interruptibility, recoverability, and priority.

Source: Hook Education -React course