The fiber object and the double-buffer tree

React cannot pause a recursive function — the call stack is a system resource it does not own. The fiber architecture solved this by replacing the call stack with a data structure React controls: a linked tree of objects it can stop and resume at any node.

What a fiber actually is. A fiber is a plain JavaScript object — one per component instance, one per DOM element in the tree. Each fiber holds: the component type, its props, its key, its current state and hooks, pointers to its child, its next sibling, and its return (parent), plus an alternate pointer to its counterpart in the other tree. The fibers form a linked tree, not an array — and that linked structure is the whole point.

A recursive tree walk lives on the call stack and cannot be paused; a linked-list walk holds its position in a plain variable, so React can stop after any fiber, store the pointer, and resume from exactly there later. Fiber is the data structure that made interruptible rendering possible. The name predates React 18 — the architecture landed in React 16 (2017) — but only React 18 turned on the concurrent features that exploit it.

The two trees: current and workInProgress. React always holds two fiber trees. The current tree is the one whose state matches what is painted on screen right now. When an update starts, React builds a workInProgress tree — cloning fibers from current as it goes, applying new props and state. Each fiber’s alternate pointer links it to its twin in the other tree, so cloning is cheap: unchanged subtrees can be reused by reference.

When the workInProgress tree is complete and committed, the two trees swap: workInProgress becomes current, and the old current tree is kept around to become the next workInProgress. This is double buffering. It guarantees the on-screen tree is never observed in a half-updated state — and it is why a render that gets interrupted and thrown away costs nothing permanent: the discarded workInProgress tree simply never commits.