How do you approach Frontend: React 18 Automatic Batching (Renders Per Update)?

React 18 batches universally. React 17 only batched inside its own SyntheticEvent dispatch.

What are common mistakes on Frontend: React 18 Automatic Batching (Renders Per Update)?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

Frontend: React 18 Automatic Batching (Renders Per Update)

MediumTypeScript

Description

This problem is paper-only - see explanation for the canonical React reasoning.

React 18 automatic batching combines multiple state updates inside the same event/microtask into a single re-render. Pre-18, only updates inside React event handlers were batched.

The auto-grader validates how many renders a sequence of state-update calls produces, given the React version.

Input: { version: 17 | 18, context: "react-event" | "promise" | "settimeout" | "native-event", numberOfSetStates }. Return the number of renders.

Rules:

React 18: any context with numberOfSetStates >= 1 produces exactly 1 render.
React 17 in react-event: 1 render.
React 17 in promise / settimeout / native-event: numberOfSetStates renders (one per call).
numberOfSetStates === 0: 0 renders.

For the auto-grader: implement renderCount(input).

Example 1

Input: input = {version:18,context:"promise",numberOfSetStates:3}

Output: 1

Explanation: React 18 batches across promise callbacks.

Example 2

Input: input = {version:17,context:"promise",numberOfSetStates:3}

Output: 3

Explanation: React 17 only batched inside React-attached event handlers.

Constraints

- numberOfSetStates >= 0

Frontend: React 18 Automatic Batching (Renders Per Update): approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (3 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 2-step hint ladder

React 18 batches universally. React 17 only batched inside its own SyntheticEvent dispatch.
Zero set-state calls = zero renders, regardless of version.

The optimal approach

Show the approach: The actual rule (worth knowing word-for-word):

- React 17 and earlier: updates were batched only when called *inside* a React-attached event handler (e.g. an `onClick`). Updates called from `setTimeout`, native event listeners (`addEventListener`), or Promise callbacks each triggered their own re-render.

- React 18+: "automatic batching" - all state updates are batched, regardless of where they're called, as long as they happen in the same microtask. This makes `React.unstable_batchedUpdates(...)` mostly obsolete (still useful for explicit grouping across awaits).

Opting out: wrap an update in `flushSync(() => setX(...))` to force a synchronous render between updates - rarely needed, but matters for things like measuring DOM after a state change before the next update.

Why this matters in interviews: "your component re-renders 3x when this button is clicked" is a typical bug-hunt question. In React 18 it almost always means three separate microtasks (e.g. three awaited promises that each call setState). The fix is either to batch them with `Promise.all` or to consolidate state into a reducer call.

Concurrent-mode subtlety: `useTransition` and `useDeferredValue` let you mark some updates as low-priority, so they can be interrupted by higher-priority updates - the renderer may then "discard" an in-progress render. This isn't "batching" exactly but it's the same family of optimizations.

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.