Lesson 39 of 80

Automatic Batching

Q: What changed about state batching in React 18, and why did the old behavior cause bugs or extra renders in code before that?

A strong answer covers: Explains batching as collapsing multiple setState calls into one re-render; States correctly that pre-18, batching only applied inside React's own event handlers; Gives a concrete example of code that used to render extra times: promise callbacks, setTimeout, or native event listeners; Knows React 18 batches automatically regardless of where the update originates.

React groups multiple state updates into one re-render instead of one per call — and since React 18, it does that everywhere, not just inside event handlers.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Automatic Batching

What interviewers actually ask about this, and what a strong answer has to cover.

What changed about state batching in React 18, and why did the old behavior cause bugs or extra renders in code before that?

A strong answer covers

Explains batching as collapsing multiple setState calls into one re-render
States correctly that pre-18, batching only applied inside React's own event handlers
Gives a concrete example of code that used to render extra times: promise callbacks, setTimeout, or native event listeners
Knows React 18 batches automatically regardless of where the update originates

Likely follow-ups

If two setState calls in the same batch both update the same piece of state, does batching change the final value, or just how many times the component renders?
What does flushSync actually do, and what's the cost of using it?
Would batching ever be something you'd deliberately want to opt out of? Give a real scenario.

Practice these with the AI interviewer →

The plain-language idea

Call setState three times in a row and you might expect three re-renders. React doesn't work that way: it batches state updates that happen close together into a single re-render. All three updates get applied, then the component renders once with the final result.

Before React 18, that batching only happened inside React's own event handlers (onClick, onChange, and so on). Anything outside that — a .then() on a fetch promise, a raw setTimeout, a native addEventListener callback — ran unbatched, so each setState call there triggered its own separate re-render. React 18 made batching automatic everywhere, closing that gap.

See it in a real thing: before and after React 18

function handleClick() {
  setCount((c) => c + 1);
  setFlag((f) => !f);
  // React 18+: one re-render, both updates applied together.
  // Pre-18: also one re-render — this is inside a React event handler.
}

function handleFetchClick() {
  fetch("/api/thing").then(() => {
    setCount((c) => c + 1);
    setFlag((f) => !f);
    // React 18+: still one re-render.
    // Pre-18: TWO re-renders — this runs after the promise resolves,
    // outside any React event handler, so each call used to fire alone.
  });
}

The click handler behaved the same in both versions. The fetch callback is where the change actually shows up: pre-18, React had no way to know two setState calls inside a .then() were related, so it rendered after each one. React 18's automatic batching applies the same "collect updates, render once" rule no matter where the updates come from.

What people usually miss

Watch out

Batching changes render count, not update correctness. Each setCount(c => c + 1) call still sees the latest pending state via the updater-function form, batched or not — batching doesn't change what value you end up with, only how many times the component renders on the way there.
It's not tied to promise microtasks specifically. The rule is "updates that happen within the same browser task before React yields get batched," which covers promises, timeouts, and native event listeners alike — it's not a special case for async/await.
flushSync is an escape hatch, not a default. Reaching for it out of habit defeats the exact optimization automatic batching was built to give you for free.
Batching is invisible when it's working. There's no error, no warning — a component that behaved fine after a version bump can start rendering fewer times, which is usually a pure win but occasionally surfaces a bug in code that assumed each setState call ran a fresh render immediately.

The genealogy: it's about counting the same triggers, not new ones

This connects directly to the earlier lesson on what actually causes a component to re-render: a state update is still the trigger. Batching doesn't change what counts as a trigger — it changes how many of those triggers collapse into a single actual render pass.