Render and Commit

Notes on the pipeline every React update goes through, from react.dev’s Render and Commit, Andrew Clark’s React Fiber Architecture, and the React 19.2 source (react-dom-client.development.js). This is the entry point of React Internals. The later notes zoom into each box of the diagram below. My own notes and clarifications are marked with > 💬.

Interview Q&A

The pipeline

react.dev describes the first three steps with a restaurant analogy. Triggering delivers the guest’s order to the kitchen, rendering prepares the order in the kitchen, and committing places it on the table.

1. Trigger

There are only two reasons a component renders (react.dev):

1. “It’s the component’s initial render” (root.render(<App />)).
2. “The component’s (or one of its ancestors’) state has been updated.”

Context changes and a parent re-rendering are really cases of (2): someone’s state changed and React re-rendered from there downward. Props never trigger anything by themselves. See React Re-rendering.

Internally a trigger doesn’t start work right away. setState creates an update object, assigns it a priority (lane), marks the path from the component to the root, and asks the root to be scheduled. Several setStates in the same event land in the same lane and produce one render (automatic batching). See Scheduler, Lanes and Batching.

2. Render phase

react.dev: “On initial render, React will call the root component. For subsequent renders, React will call the function component whose state update triggered the render. This process is recursive.”

Under the hood React walks the fiber tree one fiber at a time (The Work Loop):

• Going down (beginWork), React calls the component, or bails out if nothing changed, and reconciles the returned elements against the existing child fibers. Reconciling means deciding what to reuse, update, create or delete (Reconciliation, Child Reconciliation Algorithm).
• Coming back up (completeWork), React creates DOM nodes for new host elements (not yet attached to the document), flags existing ones that got new props, and bubbles “something below me needs work” flags to the parent.

Everything in this phase is built on a work-in-progress copy of the tree (React Fiber, double buffering), so the screen keeps showing the old UI the whole time. That’s what makes the phase safe to interrupt: nothing has been shown yet, so there is nothing to undo.

3. Commit phase

When the work-in-progress tree is complete, React commits it in one synchronous pass. It applies the collected DOM mutations, swaps the work-in-progress tree to be the current one, attaches refs and runs layout effects. See Commit Phase and Effects.

react.dev: “React only changes the DOM nodes if there’s a difference between renders. For example, if a component re-renders but the <input> element remains in the same position in the JSX, React won’t touch it—or its value.”

4. Paint, then passive effects

The browser recalculates styles and layout and paints. react.dev calls this “painting” “to avoid confusion” with React’s rendering. After the paint, React runs useEffect callbacks. That ordering is why effects don’t block the user from seeing the update.

Why render and commit are separate

The split exists so the expensive, error-prone part (running user code and diffing) can be done without the user seeing anything, while the part the user does see is applied all at once. Andrew Clark’s architecture doc lists the goals Fiber was built for:

• “pause work and come back to it later”
• “assign priority to different types of work”
• “reuse previously completed work”
• “abort work if it’s no longer needed”

All four are only possible in the render phase. A half-applied DOM mutation can’t be paused or aborted, so the commit phase never is. That’s why the render phase must be pure. It’s also why React can show a consistent UI while rendering concurrently (Concurrent Rendering).

The same doc separates reconciliation (“the algorithm React uses to diff one tree with another to determine which parts need to be changed”) from rendering to a host. The reconciler (react-reconciler) is shared, and React DOM and React Native are just different renderers plugged into it. The commit phase calls renderer methods like appendChild, commitUpdate and removeChild, and only the renderer knows what those mean.

“The virtual DOM”, precisely

“Virtual DOM” is a loose name for three different things:

React diffs new elements vs current fibers, not “virtual DOM vs real DOM”. The output of that diff is a set of flags on the work-in-progress fibers, which the commit phase turns into DOM calls.

Render and commit, step by step

A counter button is clicked once:

function Counter() {
	const [count, setCount] = useState(0)
	useEffect(() => {
		document.title = `Clicked ${count}`
	}, [count])
	return <button onClick={() => setCount(count + 1)}>{count}</button>
}

The end-to-end version with real function names is in A State Update, End to End.

Rules and caveats

• Render is pure, commit is not. Anything observable (subscriptions, mutations, requests) belongs in effects or event handlers.
• Re-render ≠ DOM update. A component can render and produce identical output. The commit then changes nothing. The cost you pay is the render itself.
• The DOM is never read to diff. If you mutate React-owned DOM behind React’s back, React won’t notice and may overwrite it.
• Strict Mode double-invokes renders (and effects on mount) in development only, to surface impurity.

Sources

• react.dev: Render and Commit
• Andrew Clark: React Fiber Architecture
• React 19.2.5 source: react-dom/cjs/react-dom-client.development.js (performWorkOnRoot, commitRoot, flushSpawnedWork)

Primary source: react.dev/learn/render-and-commit