Take a closer look at React Fiber

Original text: blog.logrocket.com/deep-dive-i…

In this paper, the core

  • When react traverses the tree, do it inside the execStack
  • When updates come in, they do this in the eventQueue (call setState)
  • Updates in the eventQueue are executed only when the execStack is empty (the delayed setState is actually executed here)

Fiber reconstructs the Stack completely, creating the Virtual Stack with puase,resume,abort, and so on

React creates a fiber Nodes tree that can be modified to handle state, props, Dom elements, and so on

Because fiber Nodes can be changed there is no need to recreate, just cloen and update __ at the same time there is no need to perform recursive traversal, instead a single linked list is created and then parent-first and depth-first traversal is created

start

“Stack” reconciler (Last-in,first out)

Start with reactdom.render (
, document.getelementByid (‘root’)).

  • <App/>Is a what?
    • <App/>The virtual DOM describes the type, attributes, and child elements of the DOM.

React elements come in two types

  • Dom Element <div></div>
  • Component Element <Button></Button>

Both of these types are simple objects. They are virtual DOM types that tell React what to render

React how to handle Component elements

<Form>
  <Button>
    Submit
  </Button>
</Form>
Copy the code
  • React will ask forms, buttons, and their props what are they rendering?
  • If the Form were a function component, React would call Render to get its rendered content
const Form = (props) = > {
  return(
    <div className="form">
      {props.form}
    </div>)}Copy the code
  • React will repeat until all Component Elment renderings are retrieved
  • This process of retrieving a Dom Element is known as reconciliation
  • After reconciliation, React can proceed to the Dom structure,
  • Either ReactDOM. Render or setState triggers reconciliation; During setState, a current tree will be rendered with minimal granularity through the New State tree and Rendered tree diff

Frame drops are likely to occur if setState is executed immediately

The current device FPS is generally at 60fps, i.e. 1/60≈16ms per frame. If the render time of React is longer than 16ms, the render will not be rendered properly when the render reaches 16ms, which is called frame drop. However, in reality we only have 10ms to finish rendering because the browser has to do other things.

How does Fiber work

Fiber’s four goals

  • Assign different priorities to different types of rendering
  • Pause rendering and come back later
  • Terminate rendering if no longer needed
  • Reuse the calculated rendering

The challenge with Fiber is how the JavaScript engine works and how multithreading works.

Let’s take a look at how JavaScript engines work (execution environment)

  • The JavaScript engine starts by creating the global execution environment (Window in Browser, global in Node)execStack: [globalExecContext]
function a() {
  console.log("i am a")
  b()
}

function b() {
  console.log("i am b")
}

a()
Copy the code
  • When a is executed, the execution environment of A is created and pushed globallyexecStack: [aExecContext, globalExecContext]
  • Because B executes in A, it also creates b’s execution environment and pushes it globally{execStack: [bExecContext, aExecContext, globalExecContext]}
  • There’s an eventQueue for asynchrony{execStack: [aExecContext, globalExecContext], eventQueue: {http}
  • The JavaScript engine will only traverse the eventQueue if the execStack is empty or if there is only globalExecContext

Back to the Stack Reconciler in React

  • When react traverses the tree, do it inside the execStack
  • When updates come in, they do this in the eventQueue (call setState)
  • Updates in the eventQueue are executed only when the execStack is empty (the delayed setState is actually executed here)

What the hell Fiber did

Fiber reconstructs the Stack completely, creating the Virtual Stack with puase,resume,abort, and so on