What setState really does

Three set calls, one render

Queueing a series of state updates showed what happens when you call a set function three times: React waits for your handler, queues the three updates, and renders once. How hooks work inside showed where the queue lives: on the useState hook, in hook.queue. This lesson follows one set call through React 19.3.1's source, from your click to the render that applies it. Click Add 3 teas:

1import { useState } from "react";2import { UpdateSpy } from "./UpdateSpy.jsx";3 4function TeaCart() {5  const [count, setCount] = useState(0);6 7  function addThree() {8    setCount((c) => c + 1);9    setCount((c) => c + 1);10    setCount((c) => c + 1);11  }12 13  return <button onClick={addThree}>Add 3 teas ({count})</button>;14}15 16export default function App() {17  return (18    <UpdateSpy>19      <TeaCart />20    </UpdateSpy>21  );22}

Lines 8 to 10 call setCount three times with an updater function. Line 19 puts TeaCart inside UpdateSpy, from the UpdateSpy.jsx tab, which watches the queue of TeaCart's first hook and lists what React does with it. (Like the hooks lesson's inspector, it reads private fields: for looking only.) After one click, the log has five lines:

1. After the handler: the fiber's lanes is 2 and so is root.pendingLanes, but queue.pending is still null. React knows work is waiting, but the updates aren't in the queue yet.
2. Three Ring lines: when the render starts, React links the three update objects into a ring, one at a time. Each has lane 2 and your updater as its action. The first also has eagerState 1.
3. A render took the ring: the render moved the updates out of queue.pending to work through them. The button now says Add 3 teas (3).

The rest of this lesson explains each line. Here is the whole path first:

setCount is dispatchSetState, bound to one hook

Where does setCount come from? mountState makes it on the first render, right after mountStateImpl made the hook and its queue. This is the whole function, at ReactFiberHooks.js, lines 1948 to 1960:

function mountState<S>(
  initialState: (() => S) | S,
): [S, Dispatch<BasicStateAction<S>>] {
  const hook = mountStateImpl(initialState);
  const queue = hook.queue;
  const dispatch: Dispatch<BasicStateAction<S>> = dispatchSetState.bind(
    null,
    currentlyRenderingFiber,
    queue,
  ) as any;
  queue.dispatch = dispatch;
  return [hook.memoizedState, dispatch];
}

1. Line 4 makes the hook and its queue. Line 5 takes the queue.
2. Lines 6 to 10 make the set function: dispatchSetState.bind(null, currentlyRenderingFiber, queue). bind makes a new function with the first arguments fixed in place (see call, apply, and bind): this component's fiber and this hook's queue. When you call setCount(5), React gets dispatchSetState(fiber, queue, 5).
3. Line 11 keeps it in queue.dispatch, and line 12 returns it next to the state. Later renders return queue.dispatch again, so it's the same function every time.

See it on a live set function. Click Render again:

1import { useReducer, useState } from "react";2 3function cartReducer(items, tea) {4  return [...items, tea];5}6 7export default function App() {8  const [count, setCount] = useState(0);9  const [items, addItem] = useReducer(cartReducer, []);10  const [firstSetCount] = useState(() => setCount);11 12  return (13    <>14      <p>setCount.name: {setCount.name}</p>15      <p>addItem.name: {addItem.name}</p>16      <p>The same setCount as on the first render: {String(setCount === firstSetCount)}</p>17      <button onClick={() => setCount(count + 1)}>Render again ({count})</button>18    </>19  );20}

Line 14 prints bound dispatchSetState: a function made with bind is named after the function it binds. Line 15 prints bound dispatchReducerAction, useReducer's version. Line 10 keeps the first render's setCount (an initializer function runs only on mount), and line 16 compares: true, even after you click. That's why setCount is safe to leave out of an Effect's dependencies.

When you call it, dispatchSetState does two things. This is the function, shortened from lines 3626 to 3654; the cut lines warn about a second argument and tell DevTools about the update.

function dispatchSetState<S, A>(
  fiber: Fiber,
  queue: UpdateQueue<S, A>,
  action: A,
): void {
  // …
  const lane = requestUpdateLane(fiber);
  const didScheduleUpdate = dispatchSetStateInternal(
    fiber,
    queue,
    action,
    lane,
  );
  // …
}

Line 7 asks requestUpdateLane how urgent this update is; the next section shows the answer. Lines 8 to 13 hand everything to dispatchSetStateInternal, which does the rest of this lesson's work: it makes the update, tries the eager state, queues the update, and schedules the root.

Each call makes an update object

Every set call makes one plain object. Here is its type, and the type of the queue it joins, at lines 167 to 183:

export type Update<S, A> = {
  lane: Lane,
  revertLane: Lane,
  action: A,
  hasEagerState: boolean,
  eagerState: S | null,
  next: Update<S, A>,
  gesture: null | ScheduledGesture, // enableGestureTransition
};

export type UpdateQueue<S, A> = {
  pending: Update<S, A> | null,
  lanes: Lanes,
  dispatch: (A => mixed) | null,
  lastRenderedReducer: ((S, A) => S) | null,
  lastRenderedState: S | null,
};

And here dispatchSetStateInternal makes one, at lines 3662 to 3670:

  const update: Update<S, A> = {
    lane,
    revertLane: NoLane,
    gesture: null,
    action,
    hasEagerState: false,
    eagerState: null,
    next: null as any,
  };

Line 2 is the lane from dispatchSetState, and line 5 is your action: whatever you passed, a value or a function. Lines 6 and 7 start with no eager state, and line 8 with no next. How to read the table: each row is one field, what it holds, and its value for the first update of Add 3 teas.

The queue (lines 11 to 17 of the types) keeps pending, the ring of updates; lanes, used to tie transitions together; dispatch, your set function; and the reducer and state of the last render, which the eager state uses.

A lane is a priority written as one bit of a number. You'll meet lanes properly in the lanes lesson; for now, a few values are enough. They are in ReactFiberLane.js:

export const SyncLane: Lane = /*                        */ 0b0000000000000000000000000000010;
// …
export const InputContinuousLane: Lane = /*             */ 0b0000000000000000000000000001000;
// …
export const DefaultLane: Lane = /*                     */ 0b0000000000000000000000000100000;
// …
const TransitionLane1: Lane = /*                        */ 0b0000000000000000000000100000000;

Read each number from the right: SyncLane (line 1) is the second bit, 2. InputContinuousLane (line 3) is 8, for continuous input such as scrolling and dragging. DefaultLane (line 5) is 32. TransitionLane1 (line 7) is 256, the first of several transition lanes. Which one an update gets depends on where your set call runs. Try all three buttons, then press Transition a second time:

1import { startTransition, useState } from "react";2import { UpdateSpy } from "./UpdateSpy.jsx";3 4function Points() {5  const [points, setPoints] = useState(10);6 7  return (8    <p>9      Points: {points}{" "}10      <button onClick={() => setPoints((p) => p + 1)}>Click</button>{" "}11      <button onClick={() => setTimeout(() => setPoints((p) => p + 2), 0)}>Timer</button>{" "}12      <button onClick={() => startTransition(() => setPoints((p) => p + 3))}>Transition</button>13    </p>14  );15}16 17export default function App() {18  return (19    <UpdateSpy>20      <Points />21    </UpdateSpy>22  );23}

Click (line 10) gives lane 2: a click is a discrete event, the most urgent kind. Timer (line 11) calls setPoints later, outside any event, so it gets the default, lane 32; its "After the handler" line shows 0 everywhere, because the handler only started a timer. Transition (line 12) gives lane 256, and the next transition lane 512: React hands out the transition lanes in turn.

Updates wait, then join a ring

After the eager state (next section), dispatchSetStateInternal queues the update and schedules the root, at lines 3718 to 3723:

    const root = enqueueConcurrentHookUpdate(fiber, queue, update, lane);
    if (root !== null) {
      scheduleUpdateOnFiber(root, fiber, lane);
      entangleTransitionUpdate(root, queue, lane);
      return true;
    }

Line 1 queues the update and gets back the root of the tree. Line 3 schedules that root, and line 4 matters only for transitions. Queuing happens in enqueueUpdate, at ReactFiberConcurrentUpdates.js, lines 90 to 113:

function enqueueUpdate(
  fiber: Fiber,
  queue: ConcurrentQueue | null,
  update: ConcurrentUpdate | null,
  lane: Lane,
) {
  // Don't update the `childLanes` on the return path yet. If we already in
  // the middle of rendering, wait until after it has completed.
  concurrentQueues[concurrentQueuesIndex++] = fiber;
  concurrentQueues[concurrentQueuesIndex++] = queue;
  concurrentQueues[concurrentQueuesIndex++] = update;
  concurrentQueues[concurrentQueuesIndex++] = lane;

  concurrentlyUpdatedLanes = mergeLanes(concurrentlyUpdatedLanes, lane);

  // The fiber's `lane` field is used in some places to check if any work is
  // scheduled, to perform an eager bailout, so we need to update it immediately.
  // TODO: We should probably move this to the "shared" queue instead.
  fiber.lanes = mergeLanes(fiber.lanes, lane);
  const alternate = fiber.alternate;
  if (alternate !== null) {
    alternate.lanes = mergeLanes(alternate.lanes, lane);
  }
}

1. Lines 9 to 12 push four things into an array, concurrentQueues: the fiber, the queue, the update, and the lane. The update is not in queue.pending yet. The comment on lines 7 and 8 says why: a render might be running right now, and React doesn't change its queues halfway through.
2. Lines 19 to 23 mark the fiber's lanes straight away, on both copies of the fiber. Lines 16 and 17 give the reason: the eager bailout checks this field. That's the fiber.lanes 2 the spy saw after the handler.

The updates join the hook's queue when the next render starts, in finishQueueingConcurrentUpdates, which goes through the array four entries at a time. This is the part that links one update, at lines 68 to 78:

    if (queue !== null && update !== null) {
      const pending = queue.pending;
      if (pending === null) {
        // This is the first update. Create a circular list.
        update.next = update;
      } else {
        update.next = pending.next;
        pending.next = update;
      }
      queue.pending = update;
    }

1. Line 2 reads queue.pending. If it's null, line 5 points the update at itself: a ring of one.
2. Otherwise pending is the newest update, and pending.next the oldest. Line 7 points the new update at the oldest, and line 8 points the old newest at the new one.
3. Line 10 makes the new update the newest: queue.pending now points at it.

Why a ring? With pending pointing at the newest update, adding one at the end takes two pointer changes, and finding the first is one step, pending.next. No array to grow, no walk to the end. The spy's three Ring lines are lines 2 to 10 running three times: each line is the ring right after line 10, read from pending.next. The spy itself is watch in the UpdateSpy.jsx tab: it replaces queue.pending with a getter and a setter (see Getters and setters), so it hears every time React sets it.

The eager state bailout

Before queuing, dispatchSetStateInternal tries a shortcut. If nothing else is waiting, it works out the next state right away, and if that state is the same as the current one, it doesn't render at all. This is the eager state, shortened from lines 3675 to 3716; the cut lines swap the development dispatcher and hold longer comments.

    const alternate = fiber.alternate;
    if (
      fiber.lanes === NoLanes &&
      (alternate === null || alternate.lanes === NoLanes)
    ) {
      // The queue is currently empty, which means we can eagerly compute the
      // next state before entering the render phase. If the new state is the
      // same as the current state, we may be able to bail out entirely.
      const lastRenderedReducer = queue.lastRenderedReducer;
      if (lastRenderedReducer !== null) {
        // …
        try {
          const currentState: S = queue.lastRenderedState as any;
          const eagerState = lastRenderedReducer(currentState, action);
          // …
          update.hasEagerState = true;
          update.eagerState = eagerState;
          if (is(eagerState, currentState)) {
            // Fast path. We can bail out without scheduling React to re-render.
            // …
            enqueueConcurrentHookUpdateAndEagerlyBailout(fiber, queue, update);
            return false;
          }
        } catch (error) {
          // Suppress the error. It will throw again in the render phase.
        } finally {
          // …
        }
      }
    }

1. Lines 2 to 5: only if fiber.lanes and the other copy's lanes are both empty. Then nothing is waiting for this component, so the next state depends only on this update.
2. Lines 13 and 14 take the state of the last render and call lastRenderedReducer with your action, right now, inside your set call.
3. Lines 16 and 17 keep the result on the update: hasEagerState and eagerState.
4. Line 18 compares it with the current state using Object.is (see Equality). If they're the same, line 21 parks the update without scheduling anything, and line 22 returns: no render.
5. Lines 24 and 25: if your updater throws, React ignores it here; it will throw again during the render.

For useState, lastRenderedReducer is basicStateReducer, at lines 1265 to 1268:

function basicStateReducer<S>(state: S, action: BasicStateAction<S>): S {
  // $FlowFixMe[incompatible-use]: Flow doesn't like mixed types
  return typeof action === 'function' ? action(state) : action;
}

Line 3 is the rule from the queueing lesson, in one line: a function is called with the state, anything else replaces it. So the eager state calls your updater during the click. Watch it. This updater writes where it runs into a list, which no real updater should do; it's only to see. Click Add tea three times:

1import { useState } from "react";2 3const log = [];4let inHandler = false;5 6export default function App() {7  const [count, setCount] = useState(0);8 9  function addTea() {10    inHandler = true;11    setCount((c) => {12      log.push(inHandler ? "in the click handler" : "while rendering");13      return c + 1;14    });15    inHandler = false;16  }17 18  return (19    <>20      <button onClick={addTea}>Add tea ({count})</button>21      <ol>22        {log.map((where, index) => (23          <li key={index}>{where}</li>24        ))}25      </ol>26    </>27  );28}

Lines 10 and 15 mark the time inside the handler. After the first click, the list says in the click handler: the eager state called the updater on line 11. Then while rendering: in development, StrictMode calls each updater once more during the render and throws the result away. After the second click, two more lines, both while rendering. No eager state this time: the render the first click caused left its lane on the copy of the fiber that was on screen before, and that copy keeps it until React copies the fiber again. Line 2 of the excerpt saw it, so React skipped the shortcut and called the updater during the render.

Now set a value that doesn't change. Stats writes two counters into the page every 100 ms without rendering. Click Set the same count, then Add one, then Set the same count twice:

1import { useEffect, useRef, useState } from "react";2 3const counts = { calls: 0, effects: 0 };4 5function Counter() {6  counts.calls++;7  const [count, setCount] = useState(0);8  useEffect(() => {9    counts.effects++;10  });11 12  return (13    <p>14      Count: {count}{" "}15      <button onClick={() => setCount(count)}>Set the same count</button>{" "}16      <button onClick={() => setCount(count + 1)}>Add one</button>17    </p>18  );19}20 21// Writes the counters into its paragraph every 100 ms. It never renders again,22// so it doesn't change what React does with Counter.23function Stats() {24  const line = useRef(null);25  useEffect(() => {26    const timer = setInterval(() => {27      line.current.textContent = "Counter was called " + counts.calls + " times. Its effect ran " + counts.effects + " times.";28    }, 100);29    return () => clearInterval(timer);30  }, []);31  return <p ref={line} />;32}33 34export default function App() {35  return (36    <>37      <Counter />38      <Stats />39    </>40  );41}

1. At first, Counter was called 2 times and its effect ran 2 times: StrictMode calls components and runs effects twice when they mount, in development.
2. Set the same count: nothing changes. The eager state was 0, the same as the state, so line 22 of the excerpt returned before scheduling anything. Counter wasn't even called.
3. Add one: called 4 times, effect 3 times. A normal render.
4. Set the same count: called 6 times, effect still 3. The old copy still had a lane, so React skipped the shortcut and rendered. In the render, useState worked out the same state, so React stopped there: it didn't render Counter's children (the reconciliation lesson covers these bailouts), and the effect didn't run. This render also cleared the old lane.
5. Set the same count again: still 6. Both copies are clean now, so the shortcut works.

That is what react.dev means when it says React may still need to call your component before skipping its children. How to read the table: each row is a situation, whether the shortcut is tried, and what follows.

The rule for your code: the eager bailout is a speed-up React applies when it can, not a promise. A set call with the same value is cheap either way, and an updater must be pure, because React may call it in your handler, during the render, or both.

scheduleUpdateOnFiber tells the root

Rendering always starts at the root of the tree, so the root has to know there is work. enqueueConcurrentHookUpdate found the root by climbing the fiber's return pointers, and now scheduleUpdateOnFiber marks it. Shortened from ReactFiberWorkLoop.js, lines 987 to 1113:

export function scheduleUpdateOnFiber(
  root: FiberRoot,
  fiber: Fiber,
  lane: Lane,
) {
  // …
  // Mark that the root has a pending update.
  markRootUpdated(root, lane);
  // …
    ensureRootIsScheduled(root);
  // …
}

Line 8 marks the root with the lane. Line 10 makes sure the root will be rendered. The cut lines handle a render that is already running or waiting for data, and DevTools. markRootUpdated is in ReactFiberLane.js:

export function markRootUpdated(root: FiberRoot, updateLane: Lane) {
  root.pendingLanes |= updateLane;
  // …
}

Line 2 adds the lane to root.pendingLanes with |=, a bitwise OR: it switches the bit on and leaves the others alone. That is the spy's root.pendingLanes 2. But the spy also showed parent's childLanes 0. The fibers between the root and TeaCart are marked later, when the render starts, by markUpdateLaneFromFiberToRoot, shortened from lines 189 to 250:

function markUpdateLaneFromFiberToRoot(
  sourceFiber: Fiber,
  update: ConcurrentUpdate | null,
  lane: Lane,
): null | FiberRoot {
  // Update the source fiber's lanes
  sourceFiber.lanes = mergeLanes(sourceFiber.lanes, lane);
  let alternate = sourceFiber.alternate;
  if (alternate !== null) {
    alternate.lanes = mergeLanes(alternate.lanes, lane);
  }
  // Walk the parent path to the root and update the child lanes.
  let isHidden = false;
  let parent = sourceFiber.return;
  let node = sourceFiber;
  while (parent !== null) {
    parent.childLanes = mergeLanes(parent.childLanes, lane);
    alternate = parent.alternate;
    if (alternate !== null) {
      alternate.childLanes = mergeLanes(alternate.childLanes, lane);
    }
    // …
    node = parent;
    parent = parent.return;
  }
  // …
}

1. Lines 7 to 11 mark the fiber itself, on both copies, again.
2. Lines 16 to 25 climb from parent to parent. Line 17 adds the lane to each parent's childLanes: "somewhere below me, there is work in this lane". Line 20 does the same on the parent's other copy.

finishQueueingConcurrentUpdates calls it for each waiting update, right after linking it into the ring. While React renders, childLanes tells it which parts of the tree it can skip: a parent whose childLanes don't include this render's lanes has no work below it (the work loop lesson walks the tree).

How to read the table: each row is a field React marks for an update, who marks it, and when.

Batching: one microtask for many updates

ensureRootIsScheduled adds the root to a list of roots with work, then calls ensureScheduleIsScheduled, at ReactFiberRootScheduler.js, lines 154 to 169:

export function ensureScheduleIsScheduled(): void {
  // At the end of the current event, go through each of the roots and ensure
  // there's a task scheduled for each one at the correct priority.
  if (__DEV__ && ReactSharedInternals.actQueue !== null) {
    // We're inside an `act` scope.
    if (!didScheduleMicrotask_act) {
      didScheduleMicrotask_act = true;
      scheduleImmediateRootScheduleTask();
    }
  } else {
    if (!didScheduleMicrotask) {
      didScheduleMicrotask = true;
      scheduleImmediateRootScheduleTask();
    }
  }
}

Lines 4 to 9 are for tests that use act. In an app, lines 11 to 14 run: if no microtask is scheduled yet, schedule one and remember it in didScheduleMicrotask. The second and third setCount find the flag set and do nothing more. That is batching: all three updates wait for the same microtask (see Microtasks), which runs after your handler returns. Shortened from lines 259 to 348:

function processRootScheduleInMicrotask() {
  // This function is always called inside a microtask. It should never be
  // called synchronously.
  didScheduleMicrotask = false;
  // …
  // At the end of the microtask, flush any pending synchronous work. This has
  // to come at the end, because it does actual rendering work that might throw.
  // …
  if (!hasPendingCommitEffects()) {
    flushSyncWorkAcrossRoots_impl(syncTransitionLanes, false);
  }
  // …
}

Line 4 clears the flag, so the next event can schedule a new microtask. Lines 9 to 11, at the end, render the roots that have synchronous work, like a click's. Updates in other lanes, like a timer's or a transition's, get a task from the scheduler instead, which renders them a little later. You can see the microtask from your own code. This handler queues a microtask of its own before the first setCount, and another after it. Click the button:

1import { useRef, useState } from "react";2 3export default function App() {4  const [count, setCount] = useState(0);5  const [notes, setNotes] = useState([]);6  const button = useRef(null);7 8  function addThree() {9    const seen = [];10    queueMicrotask(() => seen.push("A microtask queued before setCount sees: " + button.current.textContent));11    setCount((c) => c + 1);12    queueMicrotask(() => seen.push("A microtask queued after setCount sees: " + button.current.textContent));13    setCount((c) => c + 1);14    setCount((c) => c + 1);15    seen.push("The end of the handler sees: " + button.current.textContent);16    setTimeout(() => setNotes(seen), 0);17  }18 19  return (20    <>21      <button ref={button} onClick={addThree}>Add 3 teas ({count})</button>22      <ol>23        {notes.map((note, index) => (24          <li key={index}>{note}</li>25        ))}26      </ol>27    </>28  );29}

1. The end of the handler sees: Add 3 teas (0). Line 15 runs after all three set calls, and nothing has rendered.
2. A microtask queued before setCount sees: Add 3 teas (0). Line 10's microtask was queued before React's, so it runs first, still before the render.
3. A microtask queued after setCount sees: Add 3 teas (3). Line 11's setCount queued React's microtask, so line 12's runs after it, and the page already shows 3: one render, with all three updates.

Line 16 shows the notes with a timer, after everything else. React 18 made this the rule for updates from anywhere: event handlers, timers, promises, and the code after await. The queueing lesson counted the renders; now you've seen the flag and the microtask that make it work.

The next render works through the queue

In that render, useState calls updateState, which calls updateReducerImpl with basicStateReducer. First it takes the ring out of queue.pending, shortened from lines 1333 to 1359:

  let baseQueue = hook.baseQueue;

  // The last pending update that hasn't been processed yet.
  const pendingQueue = queue.pending;
  if (pendingQueue !== null) {
    // We have new updates that haven't been processed yet.
    // We'll add them to the base queue.
    if (baseQueue !== null) {
      // Merge the pending queue and the base queue.
      const baseFirst = baseQueue.next;
      const pendingFirst = pendingQueue.next;
      baseQueue.next = pendingFirst;
      pendingQueue.next = baseFirst;
    }
    // …
    current.baseQueue = baseQueue = pendingQueue;
    queue.pending = null;
  }

1. Line 1: hook.baseQueue holds updates an earlier render skipped. It's usually null.
2. Lines 8 to 14: if both exist, React joins the two rings into one, old updates first, by swapping two next pointers.
3. Lines 16 and 17: the joined ring becomes the base queue, and queue.pending goes back to null. That is the spy's last line, A render took the ring.

Then the loop. This is a simplified version of lines 1372 to 1544: it leaves out updates made inside a hidden tree, useOptimistic and gesture updates, the StrictMode extra call, and comments. Every line it keeps is React's, except line 10, which drops the hidden-tree case from the check.

    const first = baseQueue.next;
    let newState = baseState;

    let newBaseState = null;
    let newBaseQueueFirst = null;
    let newBaseQueueLast: Update<S, A> | null = null;
    let update = first;
    do {
      const updateLane = removeLanes(update.lane, OffscreenLane);
      let shouldSkipUpdate = !isSubsetOfLanes(renderLanes, updateLane);

      if (shouldSkipUpdate) {
        const clone: Update<S, A> = {
          lane: updateLane,
          action: update.action,
          hasEagerState: update.hasEagerState,
          eagerState: update.eagerState,
          next: null as any,
        };
        if (newBaseQueueLast === null) {
          newBaseQueueFirst = newBaseQueueLast = clone;
          newBaseState = newState;
        } else {
          newBaseQueueLast = newBaseQueueLast.next = clone;
        }
        currentlyRenderingFiber.lanes = mergeLanes(
          currentlyRenderingFiber.lanes,
          updateLane,
        );
      } else {
        if (newBaseQueueLast !== null) {
          const clone: Update<S, A> = {
            lane: NoLane,
            action: update.action,
            hasEagerState: update.hasEagerState,
            eagerState: update.eagerState,
            next: null as any,
          };
          newBaseQueueLast = newBaseQueueLast.next = clone;
        }

        const action = update.action;
        if (update.hasEagerState) {
          newState = update.eagerState as any as S;
        } else {
          newState = reducer(newState, action);
        }
      }
      update = update.next;
    } while (update !== null && update !== first);

1. Lines 1 to 8: start at the oldest update, baseQueue.next, with newState set to the base state.
2. Line 10 asks whether this render includes the update's lane: isSubsetOfLanes(renderLanes, updateLane). A click's render has lane 2; a transition's update has lane 256, so it isn't included.
3. Lines 12 to 29 skip it. Line 13 makes a copy, and lines 20 to 25 add it to a new base queue. If it's the first skipped update, line 22 saves the state so far as newBaseState: the next render will start from there. Lines 26 to 29 put the lane back on the fiber, so React knows to render again.
4. Lines 30 to 47 apply it. If an earlier update was skipped, lines 31 to 40 copy this one too, with lane 0, which every render includes, so it runs again after the skipped one. Lines 43 to 47 work out the new state: the eager state if there is one, otherwise reducer(newState, action).
5. Line 49 moves on, and line 50 stops when the loop gets back to the first update.

And the end, shortened from lines 1546 to 1578:

    if (newBaseQueueLast === null) {
      newBaseState = newState;
    } else {
      newBaseQueueLast.next = newBaseQueueFirst as any;
    }

    // Mark that the fiber performed work, but only if the new state is
    // different from the current state.
    if (!is(newState, hook.memoizedState)) {
      markWorkInProgressReceivedUpdate();
      // …
    }

    hook.memoizedState = newState;
    hook.baseState = newBaseState;
    hook.baseQueue = newBaseQueueLast;

    queue.lastRenderedState = newState;

If nothing was skipped, lines 1 and 2 make the result the new base state. Line 9 tells React this component's state changed, only if it did: that's how the same-value render in the eager section stopped early. Lines 14 to 18 save the state, the base state, and the base queue on the hook. Step through it with three handlers. Pick one and press Step:

// count starts at 0
setCount((c) => c + 1);
setCount((c) => c + 1);
setCount((c) => c + 1);

Three updaters: the first update uses its eager state, 1, without calling anything; the other two are called with 1 and 2. A value, then an updater: 5 replaces the state, then (c) => c * 2 gets 5. A transition, then a click takes two renders. The click's render skips the transition's update, so the screen shows 10, with baseState 1 and two updates waiting. The transition's render starts from 1 again and applies both, in order: 20. React calls this rebasing: the waiting updates run again on top of the base state, so the result is the same as if they had all run in the order you queued them.

Here is the same handler in real React. Click Bonus:

1import { startTransition, useLayoutEffect, useRef, useState } from "react";2import { UpdateSpy } from "./UpdateSpy.jsx";3 4const screens = [];5 6function Score() {7  const [score, setScore] = useState(1);8  const line = useRef(null);9 10  useLayoutEffect(() => {11    if (screens.at(-1) !== score) screens.push(score);12    line.current.textContent = "Screens so far: " + screens.join(", ");13  });14 15  function bonus() {16    startTransition(() => setScore((s) => s + 1));17    setScore((s) => s * 10);18  }19 20  return (21    <p>22      <button onClick={bonus}>Bonus</button> Score: {score}. <span ref={line} />23    </p>24  );25}26 27export default function App() {28  return (29    <UpdateSpy>30      <Score />31    </UpdateSpy>32  );33}

Line 16 queues the transition's update and line 17 the click's. The page says Screens so far: 1, 10, 20: the layout effect on lines 10 to 13 records every score React committed. The spy shows the ring: lane 256 with eagerState 2 (the queue was empty, so the shortcut ran), then lane 2. After the handler, the fiber's lanes are 258: 256 and 2 together, two bits switched on.

An update that never renders

Knowing the eager bailout explains a classic bug. This cart adds an item by changing the array it already has. Click Add mint tea twice:

1import { useState } from "react";2 3export default function App() {4  const [items, setItems] = useState(["Green tea"]);5 6  function addMint() {7    items.push("Mint tea");8    setItems(items);9  }10 11  return (12    <>13      <button onClick={addMint}>Add mint tea</button>14      <p>15        {items.length} items: {items.join(", ")}16      </p>17    </>18  );19}

The page keeps saying 1 items: Green tea. Line 7 pushes into the same array, and line 8 passes that same array to setItems. In the eager branch, basicStateReducer returns it, and Object.is(items, items) is true: no render. Even when the shortcut doesn't run, updateReducerImpl compares with is too, and React stops before the children render. Either way, React never sees a new value. Make a new array instead (see Updating arrays in state):

1import { useState } from "react";2 3export default function App() {4  const [items, setItems] = useState(["Green tea"]);5 6  function addMint() {7    setItems([...items, "Mint tea"]);8  }9 10  return (11    <>12      <button onClick={addMint}>Add mint tea</button>13      <p>14        {items.length} items: {items.join(", ")}15      </p>16    </>17  );18}

Line 7 makes a new array, so Object.is sees a different value, and the page shows 2 items: Green tea, Mint tea. The same goes for objects: change a copy, never the state itself. Now sort the steps of a set call into the parts of React that do them:

Common mix-ups

• "setCount changes the state." No. It makes an update object and queues it. The state changes in the next render, in updateReducerImpl.
• "After setCount, the update is in hook.queue.pending." No. It waits in concurrentQueues and joins the ring when the next render starts.
• "Updaters always run during the render." No. When the queue is empty, React calls the updater inside your set call, for the eager state. That's one more reason updaters must be pure.
• "Setting the same value never calls my component." No. The eager bailout skips the render only when both copies of the fiber are free of work. Otherwise React calls the component, sees the same state, and stops before its children render.
• "React renders once per set call, then batches the paint." No. The first set call schedules one microtask, and that one render applies every queued update.
• "An urgent update can jump ahead of a transition's update and change the order." No. It renders first, but the skipped update is kept, and the next render applies everything again in the order you queued it.

Practice exercises

Predict first, then press Edit & run to check. Every answer comes from a function this lesson showed.

import { useReducer, useState } from "react";

function cartReducer(items, tea) {
  return [...items, tea];
}

export default function App() {
  const [count, setCount] = useState(0);
  const [items, addItem] = useReducer(cartReducer, []);
  const [firstSetCount] = useState(() => setCount);

  return (
    <>
      <p>setCount.name: {setCount.name}</p>
      <p>addItem.name: {addItem.name}</p>
      <p>The same setCount as on the first render: {String(setCount === firstSetCount)}</p>
      <button onClick={() => setCount(count + 1)}>Render again ({count})</button>
    </>
  );
}

1import { useReducer, useState } from "react";2 3function cartReducer(items, tea) {4  return [...items, tea];5}6 7export default function App() {8  const [count, setCount] = useState(0);9  const [items, addItem] = useReducer(cartReducer, []);10  const [firstSetCount] = useState(() => setCount);11 12  return (13    <>14      <p>setCount.name: {setCount.name}</p>15      <p>addItem.name: {addItem.name}</p>16      <p>The same setCount as on the first render: {String(setCount === firstSetCount)}</p>17      <button onClick={() => setCount(count + 1)}>Render again ({count})</button>18    </>19  );20}

import { startTransition, useState } from "react";
import { UpdateSpy } from "./UpdateSpy.jsx";

function Points() {
  const [points, setPoints] = useState(10);

  return (
    <p>
      Points: {points}{" "}
      <button onClick={() => setPoints((p) => p + 1)}>Click</button>{" "}
      <button onClick={() => setTimeout(() => setPoints((p) => p + 2), 0)}>Timer</button>{" "}
      <button onClick={() => startTransition(() => setPoints((p) => p + 3))}>Transition</button>
    </p>
  );
}

export default function App() {
  return (
    <UpdateSpy>
      <Points />
    </UpdateSpy>
  );
}

1import { startTransition, useState } from "react";2import { UpdateSpy } from "./UpdateSpy.jsx";3 4function Points() {5  const [points, setPoints] = useState(10);6 7  return (8    <p>9      Points: {points}{" "}10      <button onClick={() => setPoints((p) => p + 1)}>Click</button>{" "}11      <button onClick={() => setTimeout(() => setPoints((p) => p + 2), 0)}>Timer</button>{" "}12      <button onClick={() => startTransition(() => setPoints((p) => p + 3))}>Transition</button>13    </p>14  );15}16 17export default function App() {18  return (19    <UpdateSpy>20      <Points />21    </UpdateSpy>22  );23}

import { useState } from "react";
import { UpdateSpy } from "./UpdateSpy.jsx";

function Cups() {
  const [cups, setCups] = useState(0);

  function refill() {
    setCups(5);
    setCups((c) => c * 2);
  }

  return <button onClick={refill}>Refill ({cups})</button>;
}

export default function App() {
  return (
    <UpdateSpy>
      <Cups />
    </UpdateSpy>
  );
}

1import { useState } from "react";2import { UpdateSpy } from "./UpdateSpy.jsx";3 4function Cups() {5  const [cups, setCups] = useState(0);6 7  function refill() {8    setCups(5);9    setCups((c) => c * 2);10  }11 12  return <button onClick={refill}>Refill ({cups})</button>;13}14 15export default function App() {16  return (17    <UpdateSpy>18      <Cups />19    </UpdateSpy>20  );21}

import { useEffect, useReducer, useRef } from "react";

const counts = { calls: 0 };

function sizeReducer(size, next) {
  return next;
}

function CupSize() {
  counts.calls++;
  const [size, choose] = useReducer(sizeReducer, "Small");
  return (
    <p>
      Size: {size} <button onClick={() => choose("Small")}>Choose Small</button>
    </p>
  );
}

function Stats() {
  const line = useRef(null);
  useEffect(() => {
    const timer = setInterval(() => {
      line.current.textContent = "CupSize was called " + counts.calls + " times.";
    }, 100);
    return () => clearInterval(timer);
  }, []);
  return <p ref={line} />;
}

export default function App() {
  return (
    <>
      <CupSize />
      <Stats />
    </>
  );
}

1import { useEffect, useReducer, useRef } from "react";2 3const counts = { calls: 0 };4 5function sizeReducer(size, next) {6  return next;7}8 9function CupSize() {10  counts.calls++;11  const [size, choose] = useReducer(sizeReducer, "Small");12  return (13    <p>14      Size: {size} <button onClick={() => choose("Small")}>Choose Small</button>15    </p>16  );17}18 19function Stats() {20  const line = useRef(null);21  useEffect(() => {22    const timer = setInterval(() => {23      line.current.textContent = "CupSize was called " + counts.calls + " times.";24    }, 100);25    return () => clearInterval(timer);26  }, []);27  return <p ref={line} />;28}29 30export default function App() {31  return (32    <>33      <CupSize />34      <Stats />35    </>36  );37}

import { startTransition, useLayoutEffect, useRef, useState } from "react";

const screens = [];

export default function Score() {
  const [score, setScore] = useState(3);
  const line = useRef(null);

  useLayoutEffect(() => {
    if (screens.at(-1) !== score) screens.push(score);
    line.current.textContent = "Screens so far: " + screens.join(", ");
  });

  function bonus() {
    startTransition(() => setScore((s) => s + 5));
    setScore((s) => s * 2);
  }

  return (
    <p>
      <button onClick={bonus}>Bonus</button> <span ref={line} />
    </p>
  );
}

1import { startTransition, useLayoutEffect, useRef, useState } from "react";2 3const screens = [];4 5export default function Score() {6  const [score, setScore] = useState(3);7  const line = useRef(null);8 9  useLayoutEffect(() => {10    if (screens.at(-1) !== score) screens.push(score);11    line.current.textContent = "Screens so far: " + screens.join(", ");12  });13 14  function bonus() {15    startTransition(() => setScore((s) => s + 5));16    setScore((s) => s * 2);17  }18 19  return (20    <p>21      <button onClick={bonus}>Bonus</button> <span ref={line} />22    </p>23  );24}

import { useState } from "react";

export default function Profile() {
  const [profile, setProfile] = useState({ name: "Asha", city: "Pune" });

  function moveToMumbai() {
    profile.city = "Mumbai";
    setProfile(profile);
  }

  return (
    <p>
      {profile.name} lives in {profile.city}. <button onClick={moveToMumbai}>Move to Mumbai</button>
    </p>
  );
}

1import { useState } from "react";2 3export default function Profile() {4  const [profile, setProfile] = useState({ name: "Asha", city: "Pune" });5 6  function moveToMumbai() {7    setProfile({ ...profile, city: "Mumbai" });8  }9 10  return (11    <p>12      {profile.name} lives in {profile.city}. <button onClick={moveToMumbai}>Move to Mumbai</button>13    </p>14  );15}

Check your understanding

For each question, ask where the update is at that moment: in your set call, waiting, in the ring, or being applied.

Key takeaways

• A set function is dispatchSetState bound to one fiber and one hook's queue. It's the same function on every render.
• Each call makes an update object (lane, action, hasEagerState, eagerState, next), which waits in concurrentQueues and joins the hook's ring when the next render starts. queue.pending points at the newest; its next is the oldest.
• When nothing is waiting, React works out the next state inside your set call, and stops if it's the same. Otherwise the render decides.
• scheduleUpdateOnFiber marks the root, and one microtask renders every update queued before it: that's batching.
• updateReducerImpl applies the queue in order. Updates whose lane the render doesn't include are skipped, kept, and rebased by a later render.

Coming next: Lanes: how React prioritizes updates. It opens ReactFiberLane.js and shows how React picks which lanes to render next, and how it ties lanes together.