The Work Loop

How React walks the fiber tree during the render phase and decides which components to skip. Read from workLoopSync, workLoopConcurrentByScheduler, performUnitOfWork, completeUnitOfWork, beginWork and bailoutOnAlreadyFinishedWork in the React 19.2.5 build. Part of React Internals. It builds on React Fiber and explains the mechanism behind the React Performance module’s optimizations. My own notes and clarifications are marked with > 💬.

Interview Q&A

The problem: walking a tree without the call stack

Recursion is the natural way to walk a tree, but recursion keeps its position on the JS call stack (React Fiber explains why that’s a problem). Fiber stores the position in a variable instead. The whole render phase is these few lines:

function workLoopSync() {
	while (workInProgress !== null) performUnitOfWork(workInProgress)
}

function workLoopConcurrentByScheduler() {
	while (workInProgress !== null && !shouldYield()) performUnitOfWork(workInProgress)
}

The only difference between synchronous and concurrent rendering is the !shouldYield() check. Which loop runs depends on the update’s priority. See Scheduler, Lanes and Batching.

One unit of work: begin, then maybe complete

From the source, with profiling removed:

function performUnitOfWork(unitOfWork) {
	const current = unitOfWork.alternate
	const next = beginWork(current, unitOfWork, entangledRenderLanes)  // go DOWN
	unitOfWork.memoizedProps = unitOfWork.pendingProps
	if (next === null) {
		completeUnitOfWork(unitOfWork)   // no child → finish this one and climb
	} else {
		workInProgress = next            // descend into the first child
	}
}

function completeUnitOfWork(unitOfWork) {
	let completedWork = unitOfWork
	do {
		const returnFiber = completedWork.return
		const next = completeWork(completedWork.alternate, completedWork, entangledRenderLanes)
		if (next !== null) { workInProgress = next; return }   // rare: completeWork spawned more work
		const sibling = completedWork.sibling
		if (sibling !== null) { workInProgress = sibling; return }  // go ACROSS
		completedWork = returnFiber                                   // go UP
		workInProgress = completedWork
	} while (completedWork !== null)
	workInProgressRootExitStatus = RootCompleted   // climbed past the root: tree is done
}

beginWork and completeWork split the per-fiber work:

On mount, the DOM tree is built bottom-up, detached from the document, during completeWork. The commit then inserts only the top new node. That’s one appendChild for a whole new subtree instead of one per node.

Bailouts: how React skips work

This is where all performance tricks end up. The start of beginWork, from the 19.2.5 source:

if (current !== null) {
	if (current.memoizedProps !== workInProgress.pendingProps ||
	    workInProgress.type !== current.type) {
		didReceiveUpdate = true                          // props object changed → must render
	} else {
		if (!checkScheduledUpdateOrContext(current, renderLanes) &&
		    (workInProgress.flags & DidCapture) === 0) {
			didReceiveUpdate = false
			return attemptEarlyBailoutIfNoScheduledUpdate(current, workInProgress, renderLanes)
		}
		// ...
	}
}

checkScheduledUpdateOrContext returns true if the fiber itself has an update in the lanes being rendered, or a context it reads has changed:

function checkScheduledUpdateOrContext(current, renderLanes) {
	if ((current.lanes & renderLanes) !== 0) return true
	const dependencies = current.dependencies
	return dependencies !== null && checkIfContextChanged(dependencies)
}

If the fiber can bail out, bailoutOnAlreadyFinishedWork decides how much to skip:

function bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes) {
	if ((renderLanes & workInProgress.childLanes) === 0) {
		// (after checking for context changes propagated from above)
		return null                // NOTHING below needs work → skip the whole subtree
	}
	// something below does → clone the children (createWorkInProgress on each) and keep going
	return workInProgress.child
}

So there are three outcomes for each fiber:

childLanes is set for every queued update just before the render starts (prepareFreshStack → finishQueueingConcurrentUpdates → markUpdateLaneFromFiberToRoot). That ORs the lane into fiber.lanes and into childLanes of every ancestor up to the root. That trail of breadcrumbs is how React finds the one changed component without calling every component above it.

Where memo fits

A memo component whose parent re-rendered does get a new props object, so the !== check above says “changed”. updateMemoComponent / updateSimpleMemoComponent then run a second check, shallowEqual(prevProps, nextProps) (or your arePropsEqual), and bail out if it passes. See Memoize Components.

A second chance after rendering

Even when a function component does run, if its hooks produced no change (the state updates all computed to Object.is-equal values), then didReceiveUpdate stays false and React calls bailoutHooks + bailoutOnAlreadyFinishedWork, discarding the output and skipping the children. This is why a component that sets the same state can render once and still not re-render its children.

The work loop, step by step

function App() {
	return (
		<>
			<Header />
			<Counter />
		</>
	)
}
function Counter() {
	const [n, setN] = useState(0)
	return <button onClick={() => setN(n + 1)}>{n}</button>
}

The fiber tree is HostRoot → App → Fragment → [Header, Counter → button → "0"]. The button is clicked and setN(1) queues an update. When the render starts, Counter.lanes gets SyncLane, and so do the childLanes of Fragment, App and HostRoot.

Result: only Counter() ran. The commit walks down only where subtreeFlags is set and updates one text node (and the button’s stored props).

Step 2 is the answer to “why doesn’t App re-render when Counter’s state changes?” Updates start at the component that owns the state, and everything above it bails out.

Yielding in the concurrent loop

If this update were a transition, the loop would be workLoopConcurrentByScheduler. After each performUnitOfWork, shouldYield() checks whether the current slice has used ~5ms. If so, the loop exits, workInProgress still points at, say, the button fiber, and React asks the Scheduler to call it back. The next slice resumes at exactly that fiber. If a higher-priority update arrived in between, React instead throws the work-in-progress away (prepareFreshStack) and starts over from the root with the new lanes.

Rules and caveats

• Updates start where the state lives. Keep state as low as possible so fewer components sit between it and the fibers that read it.
• Props are compared by reference. A new JSX element means a new props object, which means a render unless memo says otherwise.
• Reusing an element skips it for free. children passed from a parent that didn’t re-render carry the same props object, so they bail out. This is the basis of Element Optimization and Provider Component.
• Context bypasses bailouts. A fiber that reads a changed context renders even if its parent bailed out and its props are identical (Optimize Context).
• Rendering ≠ committing. The loop can run a component and then discard the result (bailout after render, abandoned transitions).

Sources

• React 19.2.5 source: workLoopSync, workLoopConcurrentByScheduler, performUnitOfWork, completeUnitOfWork, beginWork, checkScheduledUpdateOrContext, bailoutOnAlreadyFinishedWork, markUpdateLaneFromFiberToRoot
• React source: ReactFiberWorkLoop.js and ReactFiberBeginWork.js
• Andrew Clark: React Fiber Architecture

Primary source: github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberWorkLoop.js