Chapter 5

useState: Batching and Async State Update Mechanics

State Is a Snapshot, Not a Mutable Variable

The most common misconception among React beginners is treating state like a plain JavaScript variable: change it, and the UI updates. This intuition is wrong — and getting it wrong leads to bugs that are genuinely hard to diagnose.

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
    // You expect count to become 3. It becomes 1.
  }

  return <button onClick={handleClick}>{count}</button>;
}

Why does clicking once add only 1 despite three setCount calls? Because throughout the entire execution of this event handler, count holds the value from the current render's snapshot — say, 0. Every call resolves to setCount(0 + 1), which is setCount(1) three times. The final result is 1.

This is intentional design. In each render, React fixes all state values at the moment rendering begins. The count you receive from useState is not a live reference that reflects every mutation — it is a constant for that render cycle, as immutable as a function argument.

Why Design It This Way?

If state were mutable, React could not guarantee rendering consistency. Imagine reading count at the start of a render, an async operation changes it midway, and you read it again — the two reads disagree. This is UI tearing, and it causes subtle visual glitches. React's snapshot model eliminates this class of problem at the architectural level.

setState Schedules, It Does Not Execute Immediately

Calling setState does not modify the current state value. It tells React: "Queue a request to update this state before the next render." React collects these requests and processes them together at an appropriate checkpoint — typically after the current event handler finishes executing.

function handleClick() {
  console.log(count); // 0
  setCount(count + 1);
  console.log(count); // Still 0, not 1
}

If you need to use the new state value for further computation immediately after setting it, you cannot read it from the state variable. Either use a local variable to track the intended new value, or use functional updates and let React sequence the computation for you.

Automatic Batching: React 18's Major Change

Batching means React merges multiple setState calls into a single render pass. This is a foundational performance optimization: if you call setName, setAge, and setLoading in one click handler, React should render once, not three times.

React 17 and Earlier: Batching Only Inside Event Handlers

In React 17, batching worked automatically only when setState was called synchronously inside a React-managed event handler. Step outside that boundary — into a setTimeout, a Promise.then, or a native DOM event listener — and each setState triggered its own render:

// React 17: 1 render (inside React event handler — batched)
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
}

// React 17: 2 renders (inside setTimeout — NOT batched)
setTimeout(() => {
  setCount(c => c + 1); // triggers render 1
  setFlag(f => !f);     // triggers render 2
}, 1000);

This inconsistency caused real bugs. Code that worked fine in synchronous handlers would unexpectedly re-render multiple times in async callbacks, sometimes causing flickering or intermediate UI states that should never be visible.

React 18: Batching Everywhere

React 18 introduced Automatic Batching, extending the merge behavior to all setState calls regardless of origin — event handlers, setTimeout, Promise callbacks, queueMicrotask, native event listeners, everything:

// React 18: 1 render regardless of context
setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
}, 1000);

fetch('/api/data').then(() => {
  setData(result);
  setLoading(false);
  // Still only 1 render
});

This improvement is powered by React 18's new concurrent rendering infrastructure and the createRoot API. If you are still using the legacy ReactDOM.render, you will not get automatic batching — it requires opting into the new root.

Upgrading to React 18 with createRoot is generally safe, but audit any code that relied on the old behavior of "each setState in async code causes an immediate render" — those assumptions no longer hold.

flushSync: Opting Out of Batching

Sometimes you genuinely need synchronous DOM updates. The canonical example is scrolling to a newly rendered element: you need the DOM to reflect the new state before you can calculate the element's position.

import { flushSync } from 'react-dom';

function handleAddItem() {
  flushSync(() => {
    setItems(prev => [...prev, newItem]);
  });
  // DOM has been updated synchronously here
  listRef.current.scrollTop = listRef.current.scrollHeight;

  flushSync(() => {
    setStatus('Item added');
  });
}

flushSync forces React to flush all pending state updates inside the callback synchronously before returning. The trade-off is real: it bypasses React's concurrent scheduling and can cause performance issues if overused. Treat it as an escape hatch for imperative DOM coordination, not a routine tool.

Functional Updates: Correct State Transitions Under Concurrency

Back to the original problem: how do you increment count by 3 in one event?

function handleClick() {
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
  // count correctly increments by 3
}

The functional form prev => prev + 1 receives the latest queued state value — not the snapshot from the current render. React processes these updater functions in sequence, feeding each function's return value as the input to the next. The chain produces the correct cumulative result.

When You Must Use Functional Updates

Rule: whenever new state depends on the previous state, use functional updates.

This rule becomes critical with closures:

// Bug: stale closure — count is always 0 inside the interval
const [count, setCount] = useState(0);
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // count captured at render time, stays 0
  }, 1000);
  return () => clearInterval(id);
}, []); // empty deps means the closure captures count=0 forever

// Fix: functional update — no dependency on the closed-over count
useEffect(() => {
  const id = setInterval(() => {
    setCount(prev => prev + 1); // React supplies the current value
  }, 1000);
  return () => clearInterval(id);
}, []);

This is the stale closure bug, one of the most common React pitfalls. When useEffect runs with an empty dependency array, its callback is created once and captures the values in scope at that moment. Even as count changes across renders, the closure holds onto the original 0.

Functional updates sidestep this entirely: instead of reading count from the closure, you hand React a function and let it apply the current value when processing the update queue. The closure no longer needs to capture count at all.

Lazy Initialization: Compute Initial State Only Once

useState accepts an initial value, but that value is only used during the first render. If computing it is expensive, passing it directly means running the computation on every render — only the first result matters, the rest are wasted:

// Wasteful: expensiveCompute() runs on every render
const [data, setData] = useState(expensiveCompute());

// Correct: pass a function — React calls it only on mount
const [data, setData] = useState(() => expensiveCompute());

When the argument is a function, React calls it exactly once during initialization. On subsequent renders, the argument is ignored entirely.

Real-World Lazy Initialization Patterns

// Safely read from localStorage (handles SSR and privacy mode)
const [theme, setTheme] = useState(() => {
  try {
    return localStorage.getItem('theme') ?? 'light';
  } catch {
    return 'light';
  }
});

// Parse URL search params without re-running on every render
const [filters, setFilters] = useState(() => {
  const params = new URLSearchParams(window.location.search);
  return {
    page: parseInt(params.get('page') ?? '1', 10),
    sort: params.get('sort') ?? 'date',
    query: params.get('q') ?? '',
  };
});

// Build initial state from expensive data transformation
const [processed, setProcessed] = useState(() =>
  rawData.map(normalizeRecord).filter(isValid)
);

The pattern is especially important when the initial state involves I/O (even synchronous I/O like localStorage), parsing, or any O(n) computation.

Deep Dive: The Stale Closure Bug

Stale closures are not limited to useEffect with timers. Any asynchronous operation can exhibit this behavior:

function SearchBox() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  async function handleSearch() {
    // query is the value at the moment handleSearch was called
    const data = await fetchResults(query);
    // If the user changed query while the fetch was in flight,
    // this still uses the old query for setting results — race condition
    setResults(data);
  }
}

This is actually a race condition, not purely a stale closure bug — but the two are related. The correct solution is aborting in-flight requests using AbortController, not trying to read the "latest" query from the closure:

useEffect(() => {
  const controller = new AbortController();

  fetchResults(query, { signal: controller.signal })
    .then(data => setResults(data))
    .catch(err => {
      if (err.name !== 'AbortError') setError(err);
    });

  return () => controller.abort(); // cancels previous request on query change
}, [query]);

Breaking Closures with useRef

For cases where you need the latest value inside a stable callback (like an event handler passed to a third-party library), the useLatest pattern is useful:

function useLatest<T>(value: T): React.RefObject<T> {
  const ref = useRef(value);
  // Update synchronously during render (before effects fire)
  ref.current = value;
  return ref;
}

function MyComponent({ onData }: { onData: (d: Data) => void }) {
  const onDataRef = useLatest(onData);

  useEffect(() => {
    const subscription = externalLibrary.subscribe(data => {
      // Always calls the latest version of onData
      onDataRef.current(data);
    });
    return () => subscription.unsubscribe();
  }, []); // Stable subscription, no need to re-subscribe when onData changes
}

The key insight: ref.current is always updated during render, so any callback that reads ref.current gets the current value — the stale closure problem doesn't apply to refs because refs are not captured by value.

Designing State Structure

How you structure state with useState has lasting implications for maintainability:

// Over-fragmented: related state scattered across multiple variables
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const [email, setEmail] = useState('');
const [isSubmitting, setIsSubmitting] = useState(false);

// Better grouping: form fields naturally belong together
const [form, setForm] = useState({
  firstName: '',
  lastName: '',
  email: '',
});
const [isSubmitting, setIsSubmitting] = useState(false);

// Updating nested state requires spreading
function handleChange(field: string, value: string) {
  setForm(prev => ({ ...prev, [field]: value }));
}

Heuristics for grouping vs. splitting:

Group state that always changes together (form fields, pagination cursor + total)
Split state that changes independently (form values vs. submission status)
If update logic involves multiple conditions and derived values, migrate to useReducer
Avoid storing derived state — compute it during render from the canonical state

Summary

useState is deceptively simple on the surface, but its design decisions have profound implications. The snapshot model guarantees render consistency. Batching prevents unnecessary work. Functional updates make state transitions correct under concurrency and async conditions. Lazy initialization prevents wasted computation on every render.

React 18's automatic batching is a meaningful behavioral change for production applications. Most code benefits silently — fewer renders, better perceived performance. Code that accidentally relied on "every setState in async code triggers an immediate render" needs review. For the rare cases where synchronous DOM updates are necessary, flushSync provides a deliberate escape hatch.

Mastering these mechanics means you can reason about state changes confidently — knowing exactly when React reads your updates, in what order, and why the value you see in your component is always exactly the value it should be.

Rate this chapter

4.9 / 5 (64 ratings)