The Work Loop - Render Phase

Where we enter

By the time you get here, an update has already been queued on a fiber and a lane assigned (root.render, setState). The root scheduler then calls into the work loop in one of two ways (Lanes & Scheduler):

• Sync lanes (e.g. a click → SyncLane): scheduleTaskForRootDuringMicrotask does not create a Scheduler task. It sets root.callbackPriority = SyncLane, and the microtask flush calls performSyncWorkOnRoot, which calls performWorkOnRoot(root, lanes, forceSync = true).¹²
• Everything else: a Scheduler task is posted with performWorkOnRootViaSchedulerTask.bind(null, root). That task first flushes any pending passive effects, recomputes getNextLanes, calls performWorkOnRoot, and returns itself as a continuation if the root still has work at that priority.³

That continuation return is how a time-sliced render picks up where it left off on the next macrotask. It is not a recursive call. Scheduler sees a function come back and keeps it as the same task.

performWorkOnRoot: the shouldTimeSlice decision

// ReactFiberWorkLoop.js (simplified)
export function performWorkOnRoot(root, lanes, forceSync) {
  if ((executionContext & (RenderContext | CommitContext)) !== NoContext) {
    throw new Error('Should not already be working.');
  }
  const shouldTimeSlice =
    (!forceSync &&
      !includesBlockingLane(lanes) &&
      !includesExpiredLane(root, lanes)) ||
    checkIfRootIsPrerendering(root, lanes);

  let exitStatus = shouldTimeSlice
    ? renderRootConcurrent(root, lanes)
    : renderRootSync(root, lanes, true);
  // ... loop handling RootInProgress / errors / store tearing ...
  finishConcurrentRender(root, exitStatus, finishedWork, lanes, renderEndTime);
  // ...
  ensureRootIsScheduled(root);
}

⁴

The decision that matters is includesBlockingLane. Its "blocking" set is SyncLane, InputContinuousLane, DefaultLane, the hydration variants of those, and GestureLane.⁵ That has a consequence people often miss:

The other two inputs:

• includesExpiredLane: a lane that has waited too long gets marked expired, and from then on it renders synchronously so it cannot be starved.
• checkIfRootIsPrerendering: if the root is only prerendering (warming up siblings of a suspended tree that can't commit yet), React always uses the concurrent loop, even for sync lanes, so that this speculative work never blocks the main thread.⁴

After the render returns, performWorkOnRoot handles a few exit cases:

• RootInProgress: the concurrent loop yielded. Break out. The scheduler task will return a continuation.
• Store tearing check: if the render was concurrent, isRenderConsistentWithExternalStores(finishedWork) walks the tree to check that every useSyncExternalStore snapshot is still current. If one changed while React was yielded, it re-renders synchronously with renderRootSync(root, lanes, false) so nothing can interleave this time.⁶
• Errors: RootErrored gets one synchronous retry via recoverFromConcurrentError. RootFatalErrored resets the stack.⁴
• Otherwise it calls finishConcurrentRender, which either commits right away or, for suspended transitions and retries, marks the root suspended and may schedule a throttled completeRootWhenReady via scheduleTimeout.⁷ completeRootWhenReady can also suspend the commit (waiting on stylesheets/images or an active View Transition) before calling completeRoot → commitRoot.⁸

renderRootSync vs renderRootConcurrent

Both functions have the same skeleton:

1. Set executionContext |= RenderContext and push the hooks dispatcher (Bootstrap).
2. If the root or the lanes changed since the last time we were here, call prepareFreshStack. If not, continue the existing work-in-progress.⁹¹⁰
3. Enter an outer: do { try { ... workLoopX() } catch (thrownValue) { handleThrow(...) } } while (true) loop.
4. Restore context. If workInProgress === null the tree is done, so clear workInProgressRoot and return the exit status. Otherwise return RootInProgress.¹¹¹²

They differ in how they handle a thrown promise (suspension) and in which inner loop they use:

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

function workLoopConcurrentByScheduler() {
  // Perform work until Scheduler asks us to yield
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

¹⁵

shouldYield is Scheduler's shouldYieldToHost. It returns true once about frameYieldMs = 5ms have passed since the current Scheduler task started, or right away if requestPaint() was called.¹⁶ So "time slicing" in practice means checking a clock between fibers, never inside a component. A single component that takes 200ms will still block for 200ms.

prepareFreshStack + createWorkInProgress for the root

prepareFreshStack is how a render starts over from scratch:

// simplified
function prepareFreshStack(root, lanes) {
  // cancel a pending timeout-commit or suspended commit, if any
  // ...
  resetWorkInProgressStack();          // unwind any half-finished WIP
  workInProgressRoot = root;
  const rootWorkInProgress = createWorkInProgress(root.current, null);
  workInProgress = rootWorkInProgress;
  workInProgressRootRenderLanes = lanes;
  workInProgressRootExitStatus = RootInProgress;
  // ... reset ~15 other module-level "workInProgressRoot*" variables ...
  entangledRenderLanes = getEntangledLanes(root, lanes);
  finishQueueingConcurrentUpdates();   // move interleaved updates onto fibers
  return rootWorkInProgress;
}

¹⁷

createWorkInProgress(current, pendingProps) is the double-buffering primitive (Fiber):

• If current.alternate === null (true for the HostRoot on the very first render), it allocates a new fiber and links wip.alternate = current; current.alternate = wip.
• Otherwise it reuses the alternate object: it resets flags (keeping only StaticMask), subtreeFlags and deletions, and copies child, memoizedProps, memoizedState, updateQueue, lanes, childLanes, sibling, index and ref from current.¹⁸

The WIP root starts out with child = current.child. In other words it begins by pointing at the current children. Children are cloned lazily, only as beginWork reaches them, either through reconciliation or through cloneChildFibers on a bailout (beginWork & Reconciliation).

The (workInProgressRoot !== root || workInProgressRootRenderLanes !== lanes) check is what makes interruption work. If a transition render yields and a click arrives, the next performWorkOnRoot call gets SyncLane. The lanes differ, so prepareFreshStack runs resetWorkInProgressStack() (which calls unwindInterruptedWork up the return path to pop contexts) and starts a new WIP from root.current.¹⁹ The half-built transition tree is simply discarded. The transition's updates are still in the queues (they were never removed, see Hooks on Update), so it is re-rendered from scratch later on top of the new state.

performUnitOfWork → beginWork / completeUnitOfWork

function performUnitOfWork(unitOfWork) {
  const current = unitOfWork.alternate;     // null => this fiber is mounting
  let next = beginWork(current, unitOfWork, entangledRenderLanes);
  unitOfWork.memoizedProps = unitOfWork.pendingProps;
  if (next === null) {
    completeUnitOfWork(unitOfWork);         // no child: go back up
  } else {
    workInProgress = next;                  // descend into the child
  }
}

²⁰

Notes:

• current is the mount/update switch for the whole render phase. current === null means "this fiber has never been committed", and every beginWork/completeWork branch tests it. On the first render the HostRoot does have a current (created by createRoot, see createRoot), but every fiber below it is brand new, so current === null all the way down. That is why the first render is a "mount" everywhere except at the root. Page 07 explains why this means only the root's direct child gets a Placement flag.
• memoizedProps = pendingProps happens right after beginWork. Next render, current.memoizedProps is what beginWork compares by identity against the new pendingProps to decide on a bailout.
• beginWork returns the first child to work on next, or null.

completeUnitOfWork is the "climb back up" half:

function completeUnitOfWork(unitOfWork) {
  let completedWork = unitOfWork;
  do {
    if ((completedWork.flags & Incomplete) !== NoFlags) {
      unwindUnitOfWork(completedWork, workInProgressRootDidSkipSuspendedSiblings);
      return;                                   // something threw below
    }
    const next = completeWork(completedWork.alternate, completedWork, entangledRenderLanes);
    if (next !== null) { workInProgress = next; return; } // rare: spawned work
    const siblingFiber = completedWork.sibling;
    if (siblingFiber !== null) { workInProgress = siblingFiber; return; }
    completedWork = completedWork.return;       // no sibling: complete parent
    workInProgress = completedWork;
  } while (completedWork !== null);
  if (workInProgressRootExitStatus === RootInProgress) {
    workInProgressRootExitStatus = RootCompleted;
  }
}

²¹

So the traversal is an iterative depth-first walk that uses three pointers per fiber (child, sibling, return) instead of the JS call stack. React used to recurse (the pre-Fiber "stack reconciler"). This design is what makes yielding possible: the entire "stack" is a single variable, workInProgress, and you can stop after any fiber and come back later.

Depth-first traversal on a small tree

function App() {
  return (
    <div>
      <h1>Hi</h1>
      <List />
    </div>
  );
}
function List() { return <ul><li>a</li><li>b</li></ul>; }

flowchart TD
  R[HostRoot] --> A[App]
  A --> D[div]
  D --> H[h1 'Hi']
  H -. sibling .-> L[List]
  L --> U[ul]
  U --> LA[li 'a']
  LA -. sibling .-> LB[li 'b']

Order of calls (B = beginWork, C = completeWork):

Every parent completes after all its children, which is why the DOM can be built bottom-up off-screen (completeWork).

First render vs update, in the loop

The update case is the big performance property: a setState deep in the tree does not re-render from the root. beginWork runs on the ancestors, sees they have no work of their own (checkScheduledUpdateOrContext is false), and bailoutOnAlreadyFinishedWork just clones the child pointers down the childLanes trail. Details are in beginWork & Reconciliation.

Interruption, resumption and suspension (brief)

• Yield: workLoopConcurrentByScheduler exits with workInProgress !== null → renderRootConcurrent returns RootInProgress → the Scheduler task returns a continuation. On the next task, workInProgressRoot === root && lanes match, so there is no prepareFreshStack and the loop simply resumes at workInProgress.¹⁰
• Interrupt: higher-priority lanes arrive → lanes mismatch → prepareFreshStack → the old WIP is thrown away (see above).
• Suspend: a component calls use(promise) or throws a promise. That surfaces as a throw out of beginWork, caught by the try/catch in the render function and handed to handleThrow, which records a workInProgressSuspendedReason (e.g. SuspendedOnImmediate / SuspendedOnData).²³ In a concurrent render, React can wait for the promise without unwinding (thenable.then(onResolution, onResolution); break outer) and later replay only that one fiber (replaySuspendedUnitOfWork) instead of re-rendering the subtree.¹⁴ In a sync render it unwinds immediately to the nearest Suspense boundary, which shows its fallback.

Finishing → commit

When completeUnitOfWork climbs past the HostRoot, workInProgress becomes null and the exit status becomes RootCompleted. performWorkOnRoot reads finishedWork = root.current.alternate, which is the finished WIP root. It calls finishConcurrentRender → completeRootWhenReady → completeRoot → commitRoot.⁴⁷⁸ Despite its name, finishConcurrentRender is called for sync renders too.

At this point the WIP tree is complete. It has DOM nodes for new host fibers, flags on every fiber that needs a side effect, and subtreeFlags bubbled up so the commit can skip clean subtrees. Nothing has been inserted into the document yet. That happens in Commit Phase.

With the React Compiler

The work loop is unchanged. The compiler rewrites your component bodies and never touches react-reconciler (React Compiler). What changes is how many fibers the loop actually processes. Compiled components return cached JSX elements when their inputs haven't changed. As described on page 07, beginWork then sees oldProps === newProps for the children and bails out of whole subtrees, so in step "Fibers visited" above, the subtree under an updated component often shrinks to just the parts whose inputs really changed. Fewer performUnitOfWork calls means less render time and fewer yields. See With vs Without Compiler.

Summary

The render phase is a while loop over one global pointer, workInProgress. performWorkOnRoot decides whether to time-slice, prepareFreshStack clones the HostRoot into a work-in-progress fiber, and performUnitOfWork walks the tree depth-first: beginWork going down, completeWork coming back up. Because the whole "stack" is one variable and nothing touches the screen, React can yield, resume, or discard a half-built tree. Render can run several times and never commit, so it must be pure. Next: beginWork.

Key takeaways

• shouldTimeSlice: DefaultLane is blocking, so the initial mount runs in renderRootSync; only Transition, Retry, Idle and Offscreen lanes yield.
• Exit handling: performWorkOnRoot handles yields, re-renders synchronously if a concurrent render saw a store change (tearing), retries errors once, or calls finishConcurrentRender.
• workLoopSync vs workLoopConcurrentByScheduler: the concurrent loop checks shouldYield() between fibers, never inside a component.
• prepareFreshStack: resets render state, creates the root WIP and drains interleaved updates onto fibers.
• Interruption: when the root or lanes change, the old WIP is discarded; its updates are still in the queues.
• performUnitOfWork: current === null is the mount/update switch, and memoizedProps = pendingProps sets up the next bailout check.
• completeUnitOfWork: completes a fiber, then moves to its sibling or parent, so parents complete after their children.
• Updates skip work: childLanes limits a deep setState to the path to the updated fiber plus its subtree.
• Suspension: a concurrent render can wait and replay one fiber; a sync render unwinds to the nearest Suspense boundary.

← Fiber · Index · beginWork & Reconciliation →