awesome-everything RU
↑ Back to the climb

Browser & Frontend Runtime

What the reconciler does: render vs commit

Crux React splits every update into an interruptible render phase that computes the diff and an atomic commit phase that applies DOM mutations — the gap between them is where both performance wins and bugs live.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at junior altitude — the surface
◷ 10 min

You call setState. Somewhere between that call and a pixel changing on screen, React decided which components to re-run, compared two trees, worked out the minimum set of DOM mutations, and applied them — possibly pausing halfway to let a keystroke through. The machine that does this is the fiber reconciler.

What the reconciler does. When your data changes, React figures out the smallest set of page changes that match the new data, and applies only those. The DOM is slow to mutate — touching it a thousand times is far slower than ten. React’s job is to compute the ten real changes instead of blindly redoing a thousand.

The blueprint metaphor. A naive builder would demolish the house and rebuild it whenever the blueprint changes. React is a smart builder: it keeps the current blueprint on the wall, draws the new one on a second sheet, lays them side by side, and marks only the differences. Then it sends the crew one work order with exactly those changes. Drawing the second blueprint is the render phase; handing the order over is the commit phase.

Why two phases. React splits every update into two phases. The render phase walks the component tree, runs your function components, and builds a new tree of fiber nodes — this phase is pure, produces no visible change, and since React 18 can be paused, resumed, or thrown away. The commit phase takes the finished new tree and applies the DOM mutations in one synchronous, uninterruptible burst. Everything good and everything dangerous about React performance lives in the gap between “interruptible render” and “atomic commit.”

setState → screen
RENDER PHASERe-run components · build fiber tree · diff← interruptible
COMMIT PHASEApply DOM mutations · run effects · paint← atomic, never paused

Bea · Browser types in a search box that filters a long list. Sven · Origin server narrates: “Each keystroke is a state change. React re-runs the components and diffs the new fiber tree against the current one. The list of 800 rows changed — but React finds only the 12 rows that differ and mutates just those 12 DOM nodes. The other 788 are untouched. That is why the box feels instant.”

Order the steps

A setState call travels through React to the screen. Drag the steps into order.

  1. 1 setState is called — React schedules an update
  2. 2 Render phase: re-run components, build the new fiber tree
  3. 3 Reconcile: diff the new tree against the current tree
  4. 4 Commit phase: apply the DOM mutations in one burst
  5. 5 Browser paints the changed pixels
Quiz

Why does React diff two trees instead of just rewriting the whole DOM?

Quiz

Which phase can React pause partway through?

Complete the analogy

In the builder metaphor, React keeps the current blueprint pinned to the wall and draws the new one on a second sheet, so it can compare them. Holding two versions of the tree at once — one shown, one being built — is called what?

Compute it

React's scheduler does render work in small chunks, then yields to the browser. Roughly how many milliseconds is one chunk before React checks whether it should yield?

ms
React reconciler numbers
Time-slice before shouldYield()
~5 ms
Reconciliation complexity
O(n) (heuristic)
Naive tree-diff complexity
O(n³)
Lane bitmask width
31 lanes
Commit phase
Atomic, not sliceable
Bailout comparison
Object.is per prop
Recall before you leave
  1. 01
    Why can the render phase be interrupted but not the commit phase?
  2. 02
    What is double buffering in React?
  3. 03
    Roughly how long is one React render slice before it checks shouldYield()?
Recap

React’s reconciler splits every update into a render phase (interruptible, pure, builds the new fiber tree in memory) and a commit phase (atomic, synchronous, applies DOM mutations). The render phase can be paused and resumed because it produces no visible change; the commit phase cannot because it mutates the DOM and must leave the page in a consistent state. React uses double buffering — two trees at once — so the in-progress update is never visible. The scheduler slices render work into ~5 ms chunks and yields to the browser between them, keeping the page responsive even during a large re-render.

Connected lessons
appears again in143
Continue the climb ↑The fiber object and the double-buffer tree
shortcuts expand
search
K
prev piece
k
next piece
j
cycle tier
t
this menu
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.