The work loop

A render, one fiber at a time

The fiber lesson showed the tree React keeps: one fiber per component and element, linked by child, sibling and return. This lesson shows how React walks that tree during a render. Run the cart below and read the log under it.

1import { useEffect } from "react";2import { note, showLog } from "./spy.js";3 4function CartHeader() {5  note("render CartHeader");6  return <h2>Your cart</h2>;7}8 9function CartItem({ name, price }) {10  note(`render CartItem ${name}`);11  return <li>{name + " $" + price}</li>;12}13 14function CartFooter() {15  note("render CartFooter");16  return <p>Free delivery over $20</p>;17}18 19export default function App() {20  note("render App");21  useEffect(() => showLog(), []);22 23  return (24    <section>25      <CartHeader />26      <ul>27        <CartItem key="tea" name="Tea" price={3} />28        <CartItem key="cake" name="Cake" price={4} />29      </ul>30      <CartFooter />31    </section>32  );33}

Each component calls note when React calls it (lines 5, 10, 15 and 20), so the log gets a render line. The spy.js tab makes the other lines: lines 20 to 24 there wrap document.createElement, and lines 26 to 34 wrap appendChild, the two DOM functions react-dom calls to build elements. Line 21 of App.jsx prints the log after the first commit. Read it from the top:

1. render App, then render CartHeader, then create <h2>. React doesn't call every component first. As soon as the h2 has nothing below it, React creates its DOM element.
2. Only then render CartItem Tea and its <li>, then Cake and its <li>.
3. create <ul> comes after both items, followed by two ul.appendChild(<li>): a parent's element is made after its children's, and they go straight into it.
4. create <section> is the last element, and it gets the h2, the ul and the p.
5. The last line, #root.appendChild(<section>), is the only one that touches the page. Everything before it happened on elements that weren't on the page yet.

That order isn't an accident. It's a loop in ReactFiberWorkLoop.js that goes down the tree, fiber by fiber, and back up. On the way down, it calls beginWork on each fiber; for a component, that's when React calls your function. On the way back up, it calls completeWork; for a DOM element, that's when React creates it. The picture numbers both.

Where a render starts: performWorkOnRoot

Every render starts in performWorkOnRoot, the function the source tour's stack trace showed under your component. Its first decision is which loop to use, in ReactFiberWorkLoop.js, lines 1165 to 1181:

  // We disable time-slicing in some cases: if the work has been CPU-bound
  // for too long ("expired" work, to prevent starvation), or we're in
  // sync-updates-by-default mode.
  const shouldTimeSlice =
    (!forceSync &&
      !includesBlockingLane(lanes) &&
      !includesExpiredLane(root, lanes)) ||
    // ... (five lines of comments about prerendering left out)
    checkIfRootIsPrerendering(root, lanes);

  let exitStatus: RootExitStatus = shouldTimeSlice
    ? renderRootConcurrent(root, lanes)
    : renderRootSync(root, lanes, true);

1. Lines 4 to 7: React time slices, works in short pieces, only when the render isn't forced to be synchronous, has no blocking lane, and hasn't waited too long. A lane, from the fiber lesson, is the bit that says how urgent an update is; a blocking lane is one React renders without stopping. The blocking lanes are listed in includesBlockingLane: SyncLane for clicks and typing, InputContinuousLane for events like scrolling, and DefaultLane for everything else outside a transition (plus their hydration twins and an experimental gesture lane). The lanes lesson covers them all.
2. Line 9 adds one case, rendering ahead of time while something is suspended; the concurrent rendering lesson covers it.
3. Lines 11 to 13 call renderRootConcurrent when time slicing is on, and renderRootSync when it's off.

So in React 19, clicks, typing, timers and the first root.render all render with renderRootSync. Transitions, and a few kinds of background work, get renderRootConcurrent. Both start the same way, with prepareFreshStack:

  workInProgressRoot = root;
  const rootWorkInProgress = createWorkInProgress(root.current, null);
  workInProgress = rootWorkInProgress;

Line 1 remembers which root is rendering. Line 2 calls createWorkInProgress on the root's current HostRoot fiber, which hands back its twin from the fiber lesson. Line 3 stores it in workInProgress, a variable declared once for the whole file at line 441. That variable is the loop's only state. Then renderRootSync calls the loop itself, in lines 2772 to 2777:

function workLoopSync() {
  // Perform work without checking if we need to yield between fiber.
  while (workInProgress !== null) {
    performUnitOfWork(workInProgress);
  }
}

Lines 3 to 5 are the whole loop: while there is a fiber to work on, work on it. There is no recursion and no list of fibers to visit, only workInProgress, which performUnitOfWork moves along.

performUnitOfWork: one fiber, one step

One turn of the loop is one unit of work: one fiber. Here is performUnitOfWork, with the profiling and development-only copies of its main call left out:

function performUnitOfWork(unitOfWork: Fiber): void {
  // The current, flushed, state of this fiber is the alternate. Ideally
  // nothing should rely on this, but relying on it here means that we don't
  // need an additional field on the work in progress.
  const current = unitOfWork.alternate;

  let next;
  // ... (profiling and development-only branches left out; each one makes this same call)
  next = beginWork(current, unitOfWork, entangledRenderLanes);
  unitOfWork.memoizedProps = unitOfWork.pendingProps;
  if (next === null) {
    // If this doesn't spawn new work, complete the current work.
    completeUnitOfWork(unitOfWork);
  } else {
    workInProgress = next;
  }
}

1. Line 5 takes the fiber's alternate: the copy on screen, or null on the first render. beginWork compares the two.
2. Line 9 calls beginWork, which returns the next fiber to work on: this fiber's first child, or null.
3. Line 10 records that this render used pendingProps: they become memoizedProps.
4. Lines 11 to 13: no child, so this fiber's part of the tree is done. completeUnitOfWork completes it and picks the next fiber.
5. Lines 14 and 15: there is a child, so workInProgress moves down to it, and the loop's next turn begins it.

Step through the whole walk on the overview's cart. Each press of Step runs one beginWork or completeWork, and the log on the right fills in the same lines the real log showed. Try First render first; the other two modes come up in later sections.

Watch workInProgress in the tree: it only moves down to a child, across to a sibling, or up to a return. It reaches every fiber twice, once to begin it and once to complete it, and after step 26 it falls off the top of the tree.

beginWork goes down, completeWork comes back up

What each call does depends on the fiber's work tag. Here is how beginWork chooses, in ReactFiberBeginWork.js:

  workInProgress.lanes = NoLanes;

  switch (workInProgress.tag) {
    // ... (LazyComponent left out)
    case FunctionComponent: {
      const Component = workInProgress.type;
      return updateFunctionComponent(
        current,
        workInProgress,
        Component,
        workInProgress.pendingProps,
        renderLanes,
      );
    }
    // ... (ClassComponent left out)
    case HostRoot:
      return updateHostRoot(current, workInProgress, renderLanes);
    // ... (resources and singletons left out)
    case HostComponent:
      return updateHostComponent(current, workInProgress, renderLanes);
    case HostText:
      return updateHostText(current, workInProgress);

1. Line 1 clears the fiber's lanes: whatever update it had is being handled now.
2. Line 3 switches on the work tag from the fiber lesson.
3. Lines 5 to 14: a function component goes to updateFunctionComponent, which calls your component through renderWithHooks, then turns the elements it returns into child fibers with reconcileChildren. How React matches new elements with old fibers is the reconciliation lesson.
4. Lines 16 and 17 handle the HostRoot, and lines 19 to 22 DOM elements and text. A DOM element's beginWork makes fibers for the children in its props, and changes nothing on the page.

Every branch returns the fiber's first child, or null. When it's null, completing takes over, in completeUnitOfWork:

function completeUnitOfWork(unitOfWork: Fiber): void {
  // Attempt to complete the current unit of work, then move to the next
  // sibling. If there are no more siblings, return to the parent fiber.
  let completedWork: Fiber = unitOfWork;
  do {
    // ... (unwinding after an error or a suspended child left out)
    const current = completedWork.alternate;
    const returnFiber = completedWork.return;

    let next;
    // ... (profiling and development-only branches left out; each one makes this same call)
    next = completeWork(current, completedWork, entangledRenderLanes);
    // ... (profiling left out)
    if (next !== null) {
      // Completing this fiber spawned new work. Work on that next.
      workInProgress = next;
      return;
    }

    const siblingFiber = completedWork.sibling;
    if (siblingFiber !== null) {
      // If there is more work to do in this returnFiber, do that next.
      workInProgress = siblingFiber;
      return;
    }
    // Otherwise, return to the parent
    // $FlowFixMe[incompatible-type] we bail out when we get a null
    completedWork = returnFiber;
    // Update the next thing we're working on in case something throws.
    workInProgress = completedWork;
  } while (completedWork !== null);

  // We've reached the root.
  if (workInProgressRootExitStatus === RootInProgress) {
    workInProgressRootExitStatus = RootCompleted;
  }
}

1. Lines 4 and 5 start a loop at the fiber that has no child.
2. Line 12 calls completeWork on it. Lines 14 to 18 handle the rare case where completing makes new work, such as a Suspense boundary that has to show its fallback.
3. Lines 20 to 25: if the fiber has a sibling, workInProgress moves there and the function returns, so the work loop begins the sibling next.
4. Lines 26 to 31: if not, it climbs to returnFiber, the parent, and loops to complete it too, because all of the parent's children are now done.
5. Lines 33 to 36: climbing past the root leaves workInProgress as null, and the render is marked complete.

For a new DOM element, completeWork is where it's made:

    case HostComponent: {
      popHostContext(workInProgress);
      const type = workInProgress.type;
      // ... (updates, errors and hydration left out; this is a new element)
      const rootContainerInstance = getRootHostContainer();
      const instance = createInstance(
        type,
        newProps,
        rootContainerInstance,
        currentHostContext,
        workInProgress,
      );
      // TODO: For persistent renderers, we should pass children as part
      // of the initial instance creation
      markCloned(workInProgress);
      appendAllChildren(instance, workInProgress, false, false);
      workInProgress.stateNode = instance;
      // ... (finalizing the element left out)
      bubbleProperties(workInProgress);

1. Lines 6 to 12 call createInstance, the DOM host config's function (ReactFiberConfigDOM.js, line 534), which calls document.createElement. That's the create line in the log.
2. Line 16, appendAllChildren, appends the children's DOM nodes, which already exist because the children completed first. Each one is a call to appendInitialChild, the ul.appendChild(<li>) lines in the log. The new element isn't on the page yet.
3. Line 17 stores the element in the fiber's stateNode.
4. Line 19, bubbleProperties, collects the children's notes into this fiber:

  let child = completedWork.child;
  while (child !== null) {
    newChildLanes = mergeLanes(
      newChildLanes,
      mergeLanes(child.lanes, child.childLanes),
    );

    subtreeFlags |= child.subtreeFlags;
    subtreeFlags |= child.flags;

    // Update the return pointer so the tree is consistent. This is a code
    // smell because it assumes the commit phase is never concurrent with
    // the render phase. Will address during refactor to alternate model.
    child.return = completedWork;

    child = child.sibling;
  }
  // ... (the version that also adds up render times, and the bailout branch, left out)
  completedWork.childLanes = newChildLanes;

Lines 1 to 17 loop over the children through child and sibling. Lines 3 to 6 merge each child's lanes and childLanes, and lines 8 and 9 merge its flags and subtreeFlags, with the bit operators from the fiber lesson. Line 19 stores the lanes as the fiber's childLanes. This is how the fiber lesson's subtreeFlags fill in: one level per complete step, from the leaves up. (In development builds, React runs a twin of this loop that also adds up render times for the Profiler.)

How to read the table: each row asks one question of beginWork and of completeWork.

workLoopSync and the loop that yields

renderRootConcurrent runs a second loop, workLoopConcurrentByScheduler. Compare it with workLoopSync:

/** @noinline */
function workLoopConcurrentByScheduler() {
  // Perform work until Scheduler asks us to yield
  while (workInProgress !== null && !shouldYield()) {
    // $FlowFixMe[incompatible-type] flow doesn't know that shouldYield() is side-effect free
    performUnitOfWork(workInProgress);
  }
}

Line 4 is the only difference: && !shouldYield(). Before every unit of work, the loop asks the scheduler whether it should give the main thread back. shouldYield is the scheduler's shouldYieldToHost:

function shouldYieldToHost(): boolean {
  if (!enableAlwaysYieldScheduler && enableRequestPaint && needsPaint) {
    // Yield now.
    return true;
  }
  const timeElapsed = getCurrentTime() - startTime;
  if (timeElapsed < frameInterval) {
    // The main thread has only been blocked for a really short amount of time;
    // smaller than a single frame. Don't yield yet.
    return false;
  }
  // Yield now.
  return true;
}

1. Lines 2 to 5: if React has asked for a paint, which it does after a commit, yield at once.
2. Line 6 measures how long this slice has been running.
3. Lines 7 to 11: under frameInterval, keep going. Lines 12 and 13: past it, yield.

frameInterval starts at frameYieldMs, from SchedulerFeatureFlags.js, line 11:

export const frameYieldMs = 5;

Five milliseconds. When the loop stops, workInProgress still points at the next fiber, and renderRootConcurrent returns "still in progress". The scheduler runs the rest in a later task, and the loop picks up from that same fiber. That's why the fiber tree is made of links: one pointer is enough to stop and go on. The scheduler lesson shows how those tasks are queued.

Try it. Each row below does 1 ms of busy work, and there are 100 of them. Both buttons start a timer that counts how often the browser gets a turn while React renders. Press Render now, then Render in a transition.

1import { memo, startTransition, useLayoutEffect, useState } from "react";2 3function busy(ms) {4  const end = performance.now() + ms;5  while (performance.now() < end) {}6}7 8function Row({ round, n }) {9  busy(1); // a slow row: 1 ms of work10  return <li>Tea blend {n}, round {round}</li>;11}12 13const Rows = memo(function Rows({ round }) {14  return <ul>{Array.from({ length: 100 }, (_, n) => <Row key={n} round={round} n={n} />)}</ul>;15});16 17let ticks = 0;18let ticking = false;19function startTicker() {20  ticks = 0;21  ticking = true;22  const tick = () => {23    if (!ticking) return;24    ticks += 1;25    setTimeout(tick, 0);26  };27  setTimeout(tick, 0);28}29 30export default function App() {31  const [round, setRound] = useState(0);32  const [report, setReport] = useState("Press a button.");33 34  useLayoutEffect(() => {35    if (!ticking) return;36    ticking = false;37    setReport(`While React rendered the rows, the timer ran ${ticks} times.`);38  }, [round]);39 40  function renderNow() {41    startTicker();42    setRound(round + 1);43  }44 45  function renderInTransition() {46    startTicker();47    startTransition(() => setRound(round + 1));48  }49 50  return (51    <>52      <button onClick={renderNow}>Render now</button>53      <button onClick={renderInTransition}>Render in a transition</button>54      <p>{report}</p>55      <Rows round={round} />56    </>57  );58}

Lines 19 to 28 start a timer that adds 1 to ticks every time the browser runs it, and line 37 reports the count after the commit. Render now (line 42) is a click update: workLoopSync renders all 100 rows without stopping, and the timer ran 0 times. Render in a transition (line 47) uses workLoopConcurrentByScheduler: the timer runs many times, because the browser gets a turn about every 5 ms. The exact number depends on your computer. The render takes about as long either way; what changes is that the page stays responsive.

One more branch decides the loop, in renderRootConcurrent:

      if (__DEV__ && ReactSharedInternals.actQueue !== null) {
        // `act` special case: If we're inside an `act` scope, don't consult
        // `shouldYield`. Always keep working until the render is complete.
        // This is not just an optimization: in a unit test environment, we
        // can't trust the result of `shouldYield`, because the host I/O is
        // likely mocked.
        workLoopSync();
      } else if (enableThrottledScheduling) {
        workLoopConcurrent(includesNonIdleWork(lanes));
      } else {
        workLoopConcurrentByScheduler();
      }

Lines 1 to 7: inside act, the helper tests wrap updates in, even a transition renders with workLoopSync; the comment says why. Lines 8 and 9 are a variant that yields on a fixed timer instead of asking the scheduler. It sits behind enableThrottledScheduling, which is false in 19.3.1, so react-dom uses line 11. How to read the table: each row asks one question of both loops.

Skipping work: bailouts and childLanes

After the first render, most of the tree usually hasn't changed. Click Tea $3 x 1 in the cart below, and read the log.

1import { useState } from "react";2import { clearLog, note, showLog } from "./spy.js";3 4function CartHeader() {5  note("render CartHeader");6  return <h2>Your cart</h2>;7}8 9function CartItem({ name, price }) {10  note(`render CartItem ${name}`);11  const [quantity, setQuantity] = useState(1);12 13  function addOne() {14    clearLog();15    setQuantity(quantity + 1);16    setTimeout(showLog);17  }18 19  return <li onClick={addOne}>{`${name} $${price} x ${quantity}`}</li>;20}21 22function CartFooter() {23  note("render CartFooter");24  return <p>Free delivery over $20</p>;25}26 27export default function App() {28  note("render App");29 30  return (31    <section>32      <CartHeader />33      <ul>34        <CartItem key="tea" name="Tea" price={3} />35        <CartItem key="cake" name="Cake" price={4} />36      </ul>37      <CartFooter />38    </section>39  );40}

Line 15 updates Tea's own state, and the log shows a single line: render CartItem Tea. App, CartHeader, Cake and CartFooter didn't render. But the work loop starts at the root every time, so how did it get to Tea without rendering what's above it? The start of beginWork answers it:

  if (current !== null) {
    const oldProps = current.memoizedProps;
    const newProps = workInProgress.pendingProps;

    if (
      oldProps !== newProps ||
      hasLegacyContextChanged() ||
      // ... (a development-only check for hot reloading left out)
    ) {
      // If props or context changed, mark the fiber as having performed work.
      // This may be unset if the props are determined to be equal later (memo).
      didReceiveUpdate = true;
    } else {
      // Neither props nor legacy context changes. Check if there's a pending
      // update or context change.
      const hasScheduledUpdateOrContext = checkScheduledUpdateOrContext(
        current,
        renderLanes,
      );
      if (
        !hasScheduledUpdateOrContext &&
        // If this is the second pass of an error or suspense boundary, there
        // may not be work scheduled on `current`, so we check for this flag.
        (workInProgress.flags & DidCapture) === NoFlags
      ) {
        // No pending updates or context. Bail out now.
        didReceiveUpdate = false;
        return attemptEarlyBailoutIfNoScheduledUpdate(
          current,
          workInProgress,
          renderLanes,
        );
      }

1. Lines 1 to 3: on an update there is a current fiber, so React compares its old props with the new ones.
2. Lines 5 to 12: different props objects, so this fiber has work to do.
3. Lines 16 to 19: the same props object, so React asks checkScheduledUpdateOrContext whether the fiber's own lanes hold an update for this render, or a context it reads changed.
4. Lines 20 to 32: neither, so React doesn't render it at all: it calls attemptEarlyBailoutIfNoScheduledUpdate, which ends in bailoutOnAlreadyFinishedWork:

function bailoutOnAlreadyFinishedWork(
  current: Fiber | null,
  workInProgress: Fiber,
  renderLanes: Lanes,
): Fiber | null {
  // ... (bookkeeping and profiling left out)
  // Check if the children have any pending work.
  if (!includesSomeLane(renderLanes, workInProgress.childLanes)) {
    // The children don't have any work either. We can skip them.
    // ... (a note about future work left out)
    if (current !== null) {
      // Before bailing out, check if there are any context changes in
      // the children.
      lazilyPropagateParentContextChanges(current, workInProgress, renderLanes);
      if (!includesSomeLane(renderLanes, workInProgress.childLanes)) {
        return null;
      }
    } else {
      return null;
    }
  }

  // This fiber doesn't have work, but its subtree does. Clone the child
  // fibers and continue.
  cloneChildFibers(current, workInProgress);
  return workInProgress.child;
}

1. Line 8 checks the fiber's childLanes. Lines 11 to 20: if nothing below has an update for this render, it returns null. The loop completes this fiber at once and never visits anything below it.
2. Lines 25 and 26: if something below has one, it clones the children from the current tree, without calling the component, and returns the first child, so the loop goes down.

Now go back to the playground in the performUnitOfWork section and pick Tea's quantity changes. The root, App, the section and the ul bail out and go down; only Tea renders; CartHeader, Cake and CartFooter each take one step and are done. The props check is about the same object, not equal values: App didn't render, so its old elements, with their old props objects, are reused. When a parent renders, every child gets new props objects and renders too, as the when React renders again lesson showed, unless you use memo.

When the loop ends, the commit begins

Once completeUnitOfWork climbs past the root, the render returns to performWorkOnRoot, and the finished tree goes to the commit through a chain of functions in ReactFiberWorkLoop.js:

1. performWorkOnRoot takes the finished tree as root.current.alternate (line 1222): the twin of the tree on screen.
2. finishConcurrentRender decides whether to commit now or wait, for example for a Suspense fallback. Despite its name, it handles synchronous renders too.
3. completeRootWhenReady and completeRoot lead to commitRoot, which changes the DOM (commitMutationEffects) and then swaps the trees, at lines 4047 to 4051:

  // The work-in-progress tree is now the current tree. This must come after
  // the mutation phase, so that the previous tree is still current during
  // componentWillUnmount, but before the layout phase, so that the finished
  // work is current during componentDidMount/Update.
  root.current = finishedWork;

Line 5 is the switch from the fiber lesson. To see where the render ends and the commit starts, add an item to a cart that is already on the page. Click Add mint.

1import { useState } from "react";2import { clearLog, note, showLog } from "./spy.js";3 4function CartHeader() {5  note("render CartHeader");6  return <h2>Your cart</h2>;7}8 9function CartItem({ name, price }) {10  note(`render CartItem ${name}`);11  return <li>{name + " $" + price}</li>;12}13 14export default function App() {15  note("render App");16  const [items, setItems] = useState(["Tea", "Cake"]);17 18  function addMint() {19    clearLog();20    setItems([...items, "Mint"]);21    setTimeout(showLog);22  }23 24  return (25    <section>26      <CartHeader />27      <ul>28        {items.map((name) => <CartItem key={name} name={name} price={3} />)}29      </ul>30      <button onClick={addMint} disabled={items.includes("Mint")}>Add mint</button>31    </section>32  );33}

Line 20 adds Mint, and App renders again with all its items. The log reads render App, render CartHeader, the three render CartItem lines, create <li>, and finally ul.appendChild(<li>). Mint's <li> is created in the render, by its completeWork, like before. But this time it goes into a <ul> that's already on the page, so React doesn't append it during the render. The fiber gets the Placement flag instead, and the commit does the append, after the whole render is done. The tree on screen never shows half a render. The commit phase lesson goes through the commit step by step.

Which loop rendered this component?

When a page feels slow, the first question is often whether a render ran in one long piece or in slices. The stack answers it: the loop that called your component is on it. Press each button.

1import { startTransition, useState } from "react";2 3function loopOnTheStack() {4  Error.stackTraceLimit = 50;5  const lines = new Error().stack.split("\n");6  const names = lines.map((line) => line.trim().replace(/^at /, "").split(/[ @(]/)[0]);7  const loops = ["workLoopSync", "workLoopConcurrentByScheduler"];8  return loops.find((name) => names.includes(name)) ?? "neither";9}10 11function Probe({ round }) {12  const loop = loopOnTheStack();13  return <p>Round {round} was rendered by {loop}.</p>;14}15 16export default function App() {17  const [round, setRound] = useState(0);18 19  return (20    <>21      <button onClick={() => setRound(round + 1)}>After a click</button>22      <button onClick={() => startTransition(() => setRound(round + 1))}>In a transition</button>23      <button onClick={() => setTimeout(() => setRound(round + 1), 0)}>From a timer</button>24      <Probe round={round} />25    </>26  );27}

Lines 3 to 9 make an Error without throwing it, cut each line of its stack down to a function's name (line 6), and look for the two loops (the stack trace API lesson explains stack and stackTraceLimit). Comparing names, not the whole text, matters here: the live preview loads your file from an address that holds its own source code, so the stack's text contains every word you wrote. The first render and After a click show workLoopSync. In a transition shows workLoopConcurrentByScheduler. From a timer shows workLoopSync: an update from a timer gets DefaultLane, which is blocking in React 19, so it can't be sliced. If a slow update from a timer or a fetch makes the page stutter, wrapping it in startTransition is what moves it to the slicing loop. These function names are React's internals, not an API: the production build shortens them, and any release can rename them. Read them to learn, never in an app's code.

The same names show up in the browser's Performance panel. Record a slow click, and you'll see one long task with performWorkOnRoot, workLoopSync, performUnitOfWork and beginWork inside it. A transition shows many short tasks instead. The profiling lesson shows how to record one.

Common mix-ups

• "React calls every component first, then creates the DOM." No. The two are mixed, depth first: an element is created as soon as everything below it is complete, as the overview's log shows.
• "React walks the tree with recursion." No. It uses a while loop and one variable, workInProgress, moved through child, sibling and return.
• "Components that don't render aren't visited." No. beginWork still visits each fiber on the way to an update and bails out. Only subtrees with nothing in childLanes are skipped whole.
• "Every render can be paused." No. Only workLoopConcurrentByScheduler checks shouldYield. Clicks, typing and timers render to the end with workLoopSync.
• "When React yields, the render starts over." No. workInProgress keeps its place, and the next slice goes on from it. React only starts over when something more urgent arrives.
• "A time slice is one frame, about 16 ms." No. The scheduler's frameYieldMs is 5.
• "completeWork puts elements on the page." No. It builds them off the page. Only the commit attaches them to the document.

Practice exercises

import { useEffect } from "react";
import { note, showLog } from "./spy.js";

function Title() {
  note("render Title");
  return <h1>Tea shop</h1>;
}

function Badge() {
  note("render Badge");
  return <span>New</span>;
}

export default function App() {
  note("render App");
  useEffect(() => showLog(), []);

  return (
    <header>
      <Title />
      <Badge />
    </header>
  );
}

import { useEffect } from "react";
import { note, showLog } from "./spy.js";

function Title() {
  note("render Title");
  return <h1>Tea shop</h1>;
}

function Badge() {
  note("render Badge");
  return <span>New</span>;
}

export default function App() {
  note("render App");
  useEffect(() => showLog(), []);

  return (
    <header>
      <Title />
      <Badge />
    </header>
  );
}

import { useState } from "react";

function loopOnTheStack() {
  Error.stackTraceLimit = 50;
  const lines = new Error().stack.split("\n");
  const names = lines.map((line) => line.trim().replace(/^at /, "").split(/[ @(]/)[0]);
  return names.includes("workLoopSync") ? "workLoopSync" : "workLoopConcurrentByScheduler";
}

export default function App() {
  const [saved, setSaved] = useState(false);
  const loop = loopOnTheStack();

  return (
    <button onClick={() => setTimeout(() => setSaved(true), 100)}>
      {saved ? `Saved. This render ran in ${loop}.` : "Save the cart"}
    </button>
  );
}

import { useState } from "react";

function loopOnTheStack() {
  Error.stackTraceLimit = 50;
  const lines = new Error().stack.split("\n");
  const names = lines.map((line) => line.trim().replace(/^at /, "").split(/[ @(]/)[0]);
  return names.includes("workLoopSync") ? "workLoopSync" : "workLoopConcurrentByScheduler";
}

export default function App() {
  const [saved, setSaved] = useState(false);
  const loop = loopOnTheStack();

  return (
    <button onClick={() => setTimeout(() => setSaved(true), 100)}>
      {saved ? `Saved. This render ran in ${loop}.` : "Save the cart"}
    </button>
  );
}

const app = { name: "App" };
const title = { name: "Title" };
const list = { name: "List" };
const tea = { name: "Tea" };
const cake = { name: "Cake" };
app.child = title;
title.return = app;
title.sibling = list;
list.return = app;
list.child = tea;
tea.return = list;
tea.sibling = cake;
cake.return = list;

// TODO: print "begin X" and "complete X" for every fiber, in the work
// loop's order, with a loop and one variable. No recursion.
function walk(root) {
}

walk(app);

const app = { name: "App" };
const title = { name: "Title" };
const list = { name: "List" };
const tea = { name: "Tea" };
const cake = { name: "Cake" };
app.child = title;
title.return = app;
title.sibling = list;
list.return = app;
list.child = tea;
tea.return = list;
tea.sibling = cake;
cake.return = list;

function walk(root) {
  let fiber = root;
  while (fiber) {
    console.log(`begin ${fiber.name}`);
    if (fiber.child) {
      fiber = fiber.child;
      continue;
    }
    while (fiber) {
      console.log(`complete ${fiber.name}`);
      if (fiber === root) return;
      if (fiber.sibling) {
        fiber = fiber.sibling;
        break;
      }
      fiber = fiber.return;
    }
  }
}

walk(app);

const app = { name: "App" };
const title = { name: "Title" };
const list = { name: "List" };
const tea = { name: "Tea" };
const cake = { name: "Cake" };
app.child = title;
title.return = app;
title.sibling = list;
list.return = app;
list.child = tea;
tea.return = list;
tea.sibling = cake;
cake.return = list;

let workInProgress = app;
let unitsDone = 0;

// One unit: go to the child, or else to the next sibling up the tree.
function performUnitOfWork(fiber) {
  unitsDone += 1;
  if (fiber.child) return fiber.child;
  while (fiber) {
    if (fiber.sibling) return fiber.sibling;
    fiber = fiber.return;
  }
  return null;
}

function shouldYield() {
  return unitsDone === 3;
}

// TODO: stop the loop when shouldYield() says so.
function workLoop() {
  while (workInProgress !== null) {
    workInProgress = performUnitOfWork(workInProgress);
  }
}

workLoop();
console.log("paused at", workInProgress?.name);
unitsDone = 0; // a new time slice
workLoop();
console.log("finished:", workInProgress === null);

const app = { name: "App" };
const title = { name: "Title" };
const list = { name: "List" };
const tea = { name: "Tea" };
const cake = { name: "Cake" };
app.child = title;
title.return = app;
title.sibling = list;
list.return = app;
list.child = tea;
tea.return = list;
tea.sibling = cake;
cake.return = list;

let workInProgress = app;
let unitsDone = 0;

// One unit: go to the child, or else to the next sibling up the tree.
function performUnitOfWork(fiber) {
  unitsDone += 1;
  if (fiber.child) return fiber.child;
  while (fiber) {
    if (fiber.sibling) return fiber.sibling;
    fiber = fiber.return;
  }
  return null;
}

function shouldYield() {
  return unitsDone === 3;
}

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

workLoop();
console.log("paused at", workInProgress?.name);
unitsDone = 0; // a new time slice
workLoop();
console.log("finished:", workInProgress === null);

1import { useState } from "react";2import { clearLog, note, showLog } from "./spy.js";3 4function Header() {5  note("render Header");6  return <h1>Tea shop</h1>;7}8 9function ProductList() {10  note("render ProductList");11  return (12    <ul>13      <li>Green tea</li>14      <li>Black tea</li>15    </ul>16  );17}18 19export default function App() {20  note("render App");21  const [query, setQuery] = useState("");22 23  function type(event) {24    clearLog();25    setQuery(event.target.value);26    setTimeout(showLog);27  }28 29  return (30    <>31      <Header />32      <input value={query} onChange={type} placeholder="Search teas" />33      <ProductList />34    </>35  );36}

1import { useState } from "react";2import { clearLog, note, showLog } from "./spy.js";3 4function Header() {5  note("render Header");6  return <h1>Tea shop</h1>;7}8 9function ProductList() {10  note("render ProductList");11  return (12    <ul>13      <li>Green tea</li>14      <li>Black tea</li>15    </ul>16  );17}18 19function SearchBox() {20  note("render SearchBox");21  const [query, setQuery] = useState("");22 23  function type(event) {24    clearLog();25    setQuery(event.target.value);26    setTimeout(showLog);27  }28 29  return <input value={query} onChange={type} placeholder="Search teas" />;30}31 32export default function App() {33  note("render App");34 35  return (36    <>37      <Header />38      <SearchBox />39      <ProductList />40    </>41  );42}

const tea = { name: "Tea", lanes: 0b10, childLanes: 0, children: [] };
const mint = { name: "Mint", lanes: 0b100000000, childLanes: 0, children: [] };
const list = { name: "List", lanes: 0, childLanes: 0, children: [tea, mint] };
const title = { name: "Title", lanes: 0, childLanes: 0, children: [] };
const app = { name: "App", lanes: 0, childLanes: 0, children: [title, list] };

// TODO: set each fiber's childLanes to the lanes and childLanes of all its
// children, combined with |. Children first, as completeWork runs.
function complete(fiber) {
}

complete(app);
console.log(app.childLanes);

const tea = { name: "Tea", lanes: 0b10, childLanes: 0, children: [] };
const mint = { name: "Mint", lanes: 0b100000000, childLanes: 0, children: [] };
const list = { name: "List", lanes: 0, childLanes: 0, children: [tea, mint] };
const title = { name: "Title", lanes: 0, childLanes: 0, children: [] };
const app = { name: "App", lanes: 0, childLanes: 0, children: [title, list] };

function complete(fiber) {
  let childLanes = 0;
  for (const child of fiber.children) {
    complete(child);
    childLanes |= child.lanes | child.childLanes;
  }
  fiber.childLanes = childLanes;
}

complete(app);
console.log(app.childLanes);

Check your understanding

Key takeaways

• A render is a while loop over one variable, workInProgress, in ReactFiberWorkLoop.js.
• performUnitOfWork calls beginWork and goes down to the child it returns. With no child, completeUnitOfWork completes fibers and moves to a sibling, or up.
• beginWork calls your components and makes child fibers. completeWork creates DOM elements off the page and collects flags and lanes.
• Clicks, typing and timers use workLoopSync. Transitions use workLoopConcurrentByScheduler, which stops every 5 ms when shouldYield() says so, and goes on from the same fiber.
• beginWork bails out on a fiber with no update. If childLanes is empty too, it skips the whole subtree.
• When the loop finishes, the commit changes the DOM and makes the finished tree current.

Coming next: Reconciliation and the diffing algorithm.