What Actually Happens When You Call setState in React Native

You’ve called setState a thousand times. But have you ever stopped to think about what React is actually doing when you call it? Probably not, it just works. Until it doesn't.

Here’s what’s happening under the hood.

It doesn’t update state. It schedules an update.

This is the first thing most developers get wrong. The moment you call setState, the state variable doesn't change. React queues the update and processes it later.

This is why this code doesn’t work the way you’d expect:

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

const handlePress = () => {
  setCount(count + 1);
  console.log(count); // still 0
};

You called setCount. But count is still 0 on the next line. The update hasn't been applied yet; it's been scheduled.

If you need the updated value immediately, use the functional form and derive your logic from it, or use a ref alongside state.

React batches your updates

If you call setState multiple times in the same event handler, React doesn't re-render three times. It batches them into a single re-render.

const handlePress = () => {
  setCount(c => c + 1);
  setName("Andrew");
  setLoading(false);
};
// one re-render, not three

This is intentional and good for performance. React 18 extended this behavior, automatic batching now works inside setTimeout, Promise callbacks, and native event handlers too, not just React event handlers.

In React Native, this matters because every re-render that touches the UI has to communicate across the JS thread. Fewer renders = less work.

What happens after the queue is processed

Once React decides it’s time to process the update, it runs your component function again with the new state values. It builds a new virtual DOM tree and diffs it against the previous one; this is the reconciler doing its job.

Only the parts of the tree that actually changed get handed off to the native layer. In the old architecture, that meant serializing changes across the bridge to the native thread. In the new architecture (JSI), this is more direct, but the principle is the same. React doesn’t repaint everything. It’s surgical.

The bug you’ve seen but never fully understood

const [count, setCount] = useState(0);
useEffect(() => {
  setCount(count + 1);
}, [count]);

This is an infinite loop. Here’s exactly why:

1. Component mounts, count is 0
2. *useEffect runs, calls setCount(1)*
3. State updates, component re-renders with count = 1
4. *useEffect sees count changed, runs again*
5. Calls setCount(2) — and so on forever

setState inside a useEffect that depends on that same state will always retrigger itself. The fix is either removing the dependency, using a condition to break the loop, or rethinking whether you need that effect at all.

The one thing to remember

setState is a request, not a command.

You’re telling React “I’d like the state to be this.” React decides when to apply it, whether to batch it with other updates, and what to re-render as a result. The moment you treat it like a synchronous assignment, you’ll hit bugs that feel random but aren’t.

Understanding this one thing fixes a whole category of subtle mistakes.