Fiber Architecture Overview

Why Your Animation Stutters When You Filter a List

You've been there. You have a searchable product list with 5,000 items. The user types into the search input. On every keystroke, React re-renders the filtered list. During this render, the main thread is blocked for 200ms. The cursor freezes. The sidebar animation drops frames. Everything feels broken.

This is the exact problem Fiber was designed to solve. Before Fiber, React's reconciler was synchronous and recursive -- it started at the root, walked the entire tree, and couldn't stop until it was done. Fiber turned that into a loop that can pause after processing any single node.

function ProductSearch() {
  const [query, setQuery] = useState('');
  const filtered = products.filter(p =>
    p.name.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <>
      <input onChange={e => setQuery(e.target.value)} />
      {/* Before Fiber: this blocks the main thread until all 5000 items render */}
      {/* With Fiber: React can pause here and handle your next keystroke */}
      {filtered.map(p => <ProductCard key={p.id} product={p} />)}
    </>
  );
}

The Mental Model

From Stack to Fiber: Why React Had to Change

The Stack Reconciler Problem

React's original reconciler (pre-v16) used JavaScript's native call stack. When setState fired, React called render() on the root component, which called render() on children, which called render() on their children — recursively, all the way down.

// Stack reconciler call stack (simplified)
reconcile(App)
  → reconcile(Header)
    → reconcile(Logo)
    → reconcile(Nav)
  → reconcile(ProductSearch)
    → reconcile(Input)
    → reconcile(ProductList)
      → reconcile(ProductCard) × 5000  // Can't stop here

The call stack is all-or-nothing. There's no way to pause JavaScript execution mid-stack and resume later. The browser can't paint, handle events, or run animations until the entire recursive tree walk completes.

For small trees, this is invisible. For large trees, it's catastrophic: any render that takes more than 16ms (one frame at 60fps) causes dropped frames.

What Fiber Changes

Here's the key insight that makes Fiber possible. It replaces the recursive call stack with an iterative loop over a linked list. Each "frame" of work processes one fiber node, then returns control to the scheduler, which decides whether to continue or yield to the browser.

// Fiber work loop (conceptual)
while (nextUnitOfWork && !shouldYield()) {
  nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
}

This single change makes rendering interruptible. React can process 50 fiber nodes, yield to the browser for animation frames, process 50 more, handle a click event, then finish the remaining nodes.

Fiber Node Anatomy

A fiber is just a plain JavaScript object. Nothing magical about it. Here's what it contains:

// Simplified fiber node structure
const fiber = {
  // Identity
  tag: FunctionComponent,    // What type of fiber (function, class, host, etc.)
  type: ProductCard,         // The component function/class, or 'div', 'span' for host
  key: 'product-42',         // Reconciliation key

  // Tree structure (linked list, NOT array children)
  child: null,               // First child fiber
  sibling: null,             // Next sibling fiber
  return: parentFiber,       // Parent fiber (called "return" because it's where
                             // processing returns to after this fiber completes)

  // State
  pendingProps: { product },  // Props for this render
  memoizedProps: { product }, // Props from last render
  memoizedState: null,        // Hook linked list (for function components)
  updateQueue: null,          // Queued state updates

  // Effects
  flags: Update | Placement,  // What side effects to commit
  subtreeFlags: 0,            // Aggregated child flags (optimization)

  // Double buffering
  alternate: currentFiber,    // The other version of this fiber (current ↔ workInProgress)
};

{ type: 'div', children: [childA, childB, childC] }

childA.sibling = childB;
childB.sibling = childC;
childA.return = parent;
childB.return = parent;
childC.return = parent;
parent.child = childA;

The Linked List Tree

The fiber tree uses three pointers per node: child, sibling, and return. This creates a structure that can be traversed without recursion:

        App
       /
    Header ——→ ProductSearch ——→ Footer
    /                /
  Logo ——→ Nav    Input ——→ ProductList
                               /
                        ProductCard ——→ ProductCard ——→ ...

Traversal order follows a depth-first pattern:

1. Go to child (go deeper)
2. If no child, go to sibling (go sideways)
3. If no sibling, go to return (go back up) and try sibling from there
4. Repeat until back at root

The traversal processes every node exactly once. And because it's a while loop instead of recursive calls, React can stop after any step and resume from the same position later.

Double Buffering: Current and WorkInProgress

This is one of the cleverest parts of the architecture. React maintains two fiber trees at all times:

• Current tree: Represents what's currently on screen. This is the "committed" state.
• WorkInProgress tree: The tree React is building during a render. This is the "draft."

Current tree           WorkInProgress tree
(on screen)            (being built)
     App ←——alternate——→ App
    /                     /
  Header ←—alternate—→ Header (reused — nothing changed)
    |                     |
  Nav ←————alternate——→ Nav (updated — new props)

When a render starts, React clones fiber nodes from the current tree into the workInProgress tree. Nodes that haven't changed are reused directly (the alternate pointer links them). Nodes that need updates get new fibers with updated props and state.

Once the entire workInProgress tree is built and all effects are computed, React "commits" it: the workInProgress tree becomes the new current tree. This swap is a single pointer reassignment — it's instantaneous.

// Conceptual commit
root.current = workInProgressTree;
// The old current tree becomes available for reuse in the next render

This double-buffering means:

• The screen never shows a half-updated tree
• React can discard a workInProgress tree if a higher-priority update interrupts it
• Fiber nodes are recycled between renders (reduces GC pressure)

Production Scenario: The Dashboard That Dropped to 15fps

A monitoring dashboard renders 200 charts, each with a sparkline. Every 5 seconds, new data arrives and triggers a full re-render. During the render, the page freezes for 300ms — the charts don't animate, hover tooltips don't appear, and the navigation is unresponsive.

The team's first instinct was React.memo on every chart. That helped, but 80 charts still needed updates each cycle, and 80 chart renders still took 150ms synchronously.

The real fix was understanding Fiber's scheduling:

function Dashboard({ charts }) {
  const [urgentData, setUrgentData] = useState(null);
  const [chartData, setChartData] = useState(charts);

  useEffect(() => {
    const ws = new WebSocket('/api/stream');
    ws.onmessage = (event) => {
      const data = JSON.parse(event.data);
      // Urgent: update the alert banner immediately
      setUrgentData(data.alerts);
      // Deferred: update charts as a transition (interruptible)
      startTransition(() => {
        setChartData(data.charts);
      });
    };
    return () => ws.close();
  }, []);

  return (
    <>
      <AlertBanner data={urgentData} />  {/* Renders immediately */}
      <ChartGrid data={chartData} />     {/* Renders interruptibly */}
    </>
  );
}

With startTransition, the chart update is marked as a transition. Fiber processes the chart renders in chunks, yielding to the browser between chunks. The alert banner updates immediately (synchronous lane), hover tooltips still work, and animations stay at 60fps — even though the chart render takes the same total time.

Common Mistakes

Challenge

Trace the fiber traversal

4. **Menu** — no child, no sibling → return to Sidebar. Sidebar has sibling → go to Main

8. **Body** — no child, no sibling → return to Article → return to Main → return to App → done

Quiz

Key Rules