React state batching: How React groups updates for performance

I remember sitting at my desk during an on-call shift, staring at a component that was triggering three separate network requests every time a user clicked "Save." I was convinced my code was broken. It turned out I wasn't accounting for how React state updates behave in the wild. If you're a junior dev, you've probably been told that calling setState triggers a re-render. That’s true, but it’s not the whole story.

Understanding React state batching

When we talk about state batching, we're looking at a specific optimization strategy within React internals. Instead of re-rendering your component for every single state update, React waits for a tiny window—usually until the current event handler finishes executing—and then processes all the pending updates at once.

Think of it like a bus driver waiting for a few passengers at a stop instead of driving to the next block for every single person who arrives. This "waiting" period is why React rendering is so efficient. Without it, even a simple counter increment would cause multiple layout calculations, which would absolutely tank your app's performance.

Why batching matters for performance

In versions prior to React 18, batching was mostly limited to React's own event handlers. If you performed an update inside a setTimeout or a raw fetch promise, React would often render for every single call. I once spent about two days debugging a dashboard that felt sluggish; it turned out we were hitting the DOM roughly 1.4x more often than necessary because we weren't leveraging native batching behavior.

By moving to React 18 and beyond, automatic batching is the default. Whether you're calling a state setter inside an event handler, a promise, or an async function, React tries its best to group those updates. This is a core part of React rendering: Mastering State Batching and the Two-Pass Model, where the engine decides how to reconcile the UI based on the final state of the batch.

The mental model in practice

Let’s look at a quick example. Imagine you have a function that updates three different pieces of state:

JAVASCRIPT
const handleClick = () => {
  setCount(c => c + 1);
  setLoading(false);
  setItems([]);
  // React groups these into one render cycle
};

Even though I called three different setters, React sees them as one unit of work. It waits until the function finishes, calculates the new state, and then runs the rendering logic once. Understanding this is crucial, especially when you're diving into React rendering: Why state updates re-run your components. If you expect the DOM to update immediately after the first line, you’re going to be disappointed.

When batching isn't enough

Sometimes, you actually need an update to happen before the next one starts. If you rely on the previous state to calculate the next one, standard batching might lead to stale data. This is where functional updates save the day:

JAVASCRIPT
// Instead of this:
setCount(count + 1);
setCount(count + 1);

// Do this:
setCount(prev => prev + 1);
setCount(prev => prev + 1);

By passing a function to the setter, you’re telling React, "Whatever the current value is when you finally process this batch, use that." This is how you ensure your performance optimization efforts don't accidentally introduce bugs in your business logic.

If you're curious about how this ties into the broader lifecycle of your app, check out React reconciliation and component state persistence: A mental model. It explains how React keeps track of which components actually need to change during these batching cycles.

Common pitfalls

Don't get too obsessed with manual batching. I’ve seen juniors try to use flushSync from react-dom to force an immediate update. While it works, it’s an escape hatch. Use it only when you're dealing with third-party libraries that need the DOM to be in a specific state before they run their own logic. For 99% of your app, let React handle the heavy lifting.

FAQ

Q: Does batching happen in useEffect? A: Yes, but keep in mind that useEffect already runs after the render. Updates inside an effect will trigger a new render cycle, which is why you need to be careful about infinite loops.

Q: Can I turn off state batching? A: Not easily, and you shouldn't want to. It’s a foundational part of how React keeps your UI responsive.

Q: Is this related to concurrent rendering? A: Absolutely. Concurrent features rely on the ability to pause and prioritize updates, which is only possible because React has a sophisticated way of managing state changes in batches.

I'm still learning the nuances of how React 19's compiler might change these patterns. Every time I think I've mastered the render cycle, I find a new edge case in a complex form. My advice? Don't stress about the micro-optimizations until you actually see a performance bottleneck in your profiler.