What happens when you call a useState setter?

Calling a useState setter doesn't immediately change the state variable. Instead, it schedules a re-render with the new value. React batches multiple setter calls within the same event handler into a single re-render for efficiency. The new state value is only available on the next render — reading the state variable immediately after calling the setter still gives you the old value.

When you call a state setter, here's what actually happens under the hood. Understanding this sequence explains why state appears "stale" immediately after setting it.

The most important mental model: state is a snapshot tied to a specific render. When your component function runs, useState returns the state value for that render. It's like a photograph — it doesn't change. The setter doesn't modify the current snapshot; it requests a new photograph (re-render) with the updated value.

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

  function handleClick() {
    setCount(count + 1);
    console.log(count); // Still 0! State is a snapshot of THIS render.

    setCount(count + 1);
    console.log(count); // Still 0! Same snapshot.

    // Both setCount calls use count = 0
    // Result: count becomes 1, not 2
    // Because both calls say "set count to 0 + 1"
  }

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

This is the #1 source of confusion with useState. The count variable is a constant for the duration of that render. Calling setCount doesn't change it — it tells React to re-render with a new value. On the next render, useState will return the updated value.

When you need to update state based on the previous value — especially when calling the setter multiple times in the same handler — use the updater function form. Instead of passing a value, you pass a function that receives the pending state and returns the new state. React queues these updaters and applies them in order.

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

  function handleClick() {
    // ❌ Both use the snapshot value (0) — result is 1
    setCount(count + 1); // "set to 0 + 1"
    setCount(count + 1); // "set to 0 + 1" (same snapshot!)

    // ✅ Updater functions chain correctly — result is 2
    setCount(prev => prev + 1); // "take pending (0), add 1 → 1"
    setCount(prev => prev + 1); // "take pending (1), add 1 → 2"
  }

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

// How React processes updater queue:
// Initial state: 0
// Queue: [prev => prev + 1, prev => prev + 1]
// Process: 0 → 1 → 2
// Final state for next render: 2

React 18+ automatically batches all state updates — whether they happen in event handlers, timeouts, promises, or native event listeners. Multiple setter calls in the same synchronous flow result in a single re-render. This is a performance optimization that prevents unnecessary intermediate renders.

function Form() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [isValid, setIsValid] = useState(false);

  console.log('Render'); // How many times does this log?

  async function handleSubmit() {
    // All three updates are batched → ONE re-render
    setName('Alice');
    setEmail('alice@example.com');
    setIsValid(true);
    // "Render" logs once, not three times
  }

  async function handleFetch() {
    const data = await fetchUser();
    // React 18+: still batched even inside async/await!
    setName(data.name);
    setEmail(data.email);
    setIsValid(true);
    // ONE re-render (React 18+)
    // In React 17, this would be THREE re-renders (not batched in promises)
  }
}

If you call the setter with the same value as the current state (compared with Object.is), React bails out — it skips the re-render entirely. This is why immutability matters: if you mutate an object and set it back, React sees the same reference and skips the update.

const [user, setUser] = useState({ name: 'Alice', age: 30 });

// ❌ Mutation — same reference, React bails out (no re-render!)
user.name = 'Bob';
setUser(user); // Object.is(oldRef, newRef) → true → skip

// ✅ New object — different reference, React re-renders
setUser({ ...user, name: 'Bob' }); // New reference → re-render

// Primitives work intuitively:
const [count, setCount] = useState(5);
setCount(5); // Same value → React skips re-render
setCount(6); // Different value → React re-renders

This question reveals whether you truly understand React's state model or just use it mechanically. Interviewers want to hear about the snapshot mental model, batching behavior, the difference between direct values and updater functions, and the bail-out optimization. It's a question that separates developers who debug state issues quickly from those who get stuck on "why isn't my state updating?" for hours.