Understanding React Fiber: The Unit of Work

The Problem: Synchronous, Uninterruptible Rendering

Before React 16, the reconciliation process was entirely synchronous. When a state update triggered a re-render, React would walk the entire component tree, calculate the changes, and update the DOM in a single, unbroken sequence. For large applications, this could take a noticeable amount of time (e.g., >16ms), blocking the browser's main thread.

While this work was happening, the UI would be completely unresponsive. It couldn't respond to user input, run animations, or do anything else. This led to a poor user experience, often described as "jank" or UI freezing.

To understand the limitations of this old "Stack Reconciler," let's watch a short segment that sets the stage for why a change was needed.

The Solution: React Fiber

React Fiber, introduced in React 16, was a complete rewrite of the core reconciliation algorithm designed to solve this exact problem.

The fundamental idea is to break the single, monolithic rendering task into many small, discrete units of work. Each "unit of work" is called a Fiber. Because the work is now chunked, React can:

1. Process a few units of work.
2. Pause and yield control back to the browser's main thread.
3. Allow the browser to handle higher-priority tasks (like responding to a keypress or running an animation).
4. Resume its work from where it left off when the browser is idle again.

This ability to pause, resume, and prioritize work is the defining feature of the Fiber architecture.

To build an initial mental model, let's look at a conceptual implementation in plain JavaScript. The following article simulates this chunking behavior using the browser's requestIdleCallback API.

This conceptual scheduler demonstrates that at its heart, Fiber introduces a cooperative scheduling model where React no longer monopolizes the main thread.

What Exactly Is a Fiber?

Now let's move from the concept to the implementation. A Fiber is a plain JavaScript object that holds information about a component, a DOM element, or any other piece of work React needs to do.

Every element in your component tree gets a corresponding Fiber node during the rendering process. Crucially, these Fiber nodes are connected in a linked list structure. A Fiber object has properties like:

• tag: Identifies the type of the fiber (e.g., FunctionComponent, ClassComponent, HostComponent for a DOM tag like div).
• stateNode: A reference to the actual instance of the component class, function, or DOM node.
• return: A pointer to the parent Fiber.
• child: A pointer to the first child Fiber.
• sibling: A pointer to the next sibling Fiber.

This return, child, and sibling structure allows React to traverse the entire component tree without relying on recursion, which was a key limitation of the old Stack reconciler. It can walk the tree, pause at any Fiber, and resume later.

The following resource provides an excellent breakdown of the Fiber data structure by inspecting it directly in the browser.

The Fiber Work Loop: Two Trees and Two Phases

So how does React use these Fiber objects to update the UI? The process involves two parallel trees and happens in two main phases.

The Two Trees: current and workInProgress

At any given time, React maintains two Fiber trees:

1. The current tree: This tree represents the UI that is currently visible on the screen. It's the source of truth for the existing state.
2. The workInProgress tree: This is a "draft" tree where React builds the new UI off-screen. As React processes updates, it clones nodes from the current tree into the workInProgress tree and applies the changes there.

This technique is analogous to double buffering in graphics programming. By working on a draft copy, React can build the new UI incrementally without causing visual inconsistencies on the screen. If the render is interrupted, the user is still looking at the consistent current tree.

The Two Phases: Render and Commit

The entire reconciliation process is split into two distinct phases:

1. Phase 1: The Render Phase (Asynchronous, Interruptible)

   • React traverses the Fiber tree, starting from the root. This is the "work loop."
   • For each Fiber, it determines if any changes are needed (e.g., state changed, props changed).
   • It builds up the workInProgress tree in memory.
   • Crucially, this phase is pure and has no side effects. It doesn't touch the DOM. It just calculates the work to be done.
   • Because it's pure, React can safely pause, abort, or resume work in this phase.

2. Phase 2: The Commit Phase (Synchronous, Uninterruptible)

   • Once the workInProgress tree is complete, the commit phase begins.
   • React now has a complete list of all the changes needed (e.g., add this DOM node, update this attribute, remove that node).
   • It executes all these changes in one single, synchronous sequence.
   • This phase must be uninterruptible to ensure the DOM is updated consistently and the user doesn't see a partially updated UI.
   • After the commit is done, the workInProgress tree becomes the current tree, ready for the next update cycle.

This video ties these concepts together beautifully, explaining the two phases and the work loop functions (beginWork and completeWork) that traverse the tree.

Conclusion

You've just taken your first major step into React's underlying architecture. This is a complex topic, but understanding the basics of Fiber is transformative for a developer's mental model of React.

Key Takeaways:

• Fiber is the solution to UI blocking: It replaced the old synchronous "Stack" reconciler.
• A Fiber is a unit of work: It's a JavaScript object with information about a component and its position in the tree structure (via child, sibling, return pointers).
• Asynchronous Rendering: The Fiber architecture allows React to break rendering into chunks, pausing to let the browser handle high-priority tasks, and then resuming its work.
• Two Phases are Key:
  • The Render Phase is async and interruptible, where React builds a workInProgress tree in memory.
  • The Commit Phase is sync and uninterruptible, where React applies the calculated changes to the actual DOM.

Preview of the Next Lesson:

We've introduced the render and commit phases today. In our next lesson, we will zoom in on them. The goal will be to distinguish between React's render phase and commit phase and list the operations allowed in each. We'll explore why this separation is so important and what it means for how you write your components, especially when using Hooks like useEffect.