Lesson 3 of 80

useState

Q: A setInterval callback inside a component keeps calling setCount(count + 1), but the displayed count gets stuck at 1 instead of counting up. Walk me through why.

A strong answer covers: useState works via a closure over a value React keeps outside the component; The interval callback was created once, on the first render, and closed over that render's count (0); Every tick recomputes setCount(0 + 1) = 1, because it never sees a newer value of count; The fix is the functional update form, setCount(c => c + 1), which reads React's current value directly.

The hook that lets a component remember a value between renders — by closing over a slot React keeps aside for it. A closure, wearing a React hat.

16 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 4

What's the fix for the stuck-counter bug above?

Use the functional update form: setCount(c => c + 1)Call setCount twice instead of once, to force a refreshMove the useState call outside the component function

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on useState

What interviewers actually ask about this, and what a strong answer has to cover.

A setInterval callback inside a component keeps calling setCount(count + 1), but the displayed count gets stuck at 1 instead of counting up. Walk me through why.

A strong answer covers

useState works via a closure over a value React keeps outside the component
The interval callback was created once, on the first render, and closed over that render's count (0)
Every tick recomputes setCount(0 + 1) = 1, because it never sees a newer value of count
The fix is the functional update form, setCount(c => c + 1), which reads React's current value directly

Likely follow-ups

Why does the functional update form avoid this bug when the plain form doesn't?
If you called setCount three times inside one click handler, how many re-renders does that actually cause?
Why does useState(expensiveCalculation()) recompute that expensive value on every render, even though it only matters on the first one — and how would you fix that?
If you had to build the exact same 'a value that persists across calls and triggers a re-render' behavior in plain vanilla JavaScript with no React, what would you have to write yourself?

Practice these with the AI interviewer →

The plain-language idea

A component function re-runs from scratch on every render — so where does state "live" between one call and the next? Not in a normal variable; those reset every time.

useState works because React keeps a slot of memory outside the function, tied to that specific component instance. Calling useState(0) hands you the current value in that slot, plus a setter that tells React "update the slot, then re-render me." This is a closure, the exact idea from the JavaScript track — useState closes over React's internal state cell the same way any closure closes over a variable from its enclosing scope.

See it in a real thing: the bug this causes

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

  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // 🐛 always resolves to 1
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps — this effect, and its closure, only ever runs once

  return <p>{count}</p>;
}

This counter gets stuck at 1 forever. The interval callback was created once, on the first render, and it closed over that render's count — which was 0. Every tick, it computes setCount(0 + 1), over and over. It never sees 1, 2, 3 — it only ever saw 0.

useState: the stale-closure bugStep 1 of 4

Render 1 creates the interval's callback — it closes over count as it was on THIS render: 0.

What people usually miss

Watch out

Calling the setter doesn't update the variable in the current render. setCount(1) schedules a re-render; count inside the function you're currently running stays whatever it was when this render started — that's just how closures work.
State updates in the same event handler are batched. Calling setCount three times in one click handler triggers one re-render, not three — React collects updates and applies them together.
useState's initial value is only used on the very first render. useState(expensiveCalculation()) re-runs that calculation on every render even though the result is thrown away every time after the first — pass a function (useState(() => expensiveCalculation())) to run it once, lazily.
Objects and arrays in state need a new reference to trigger a re-render. state.items.push(x) mutates in place and React won't notice; setState([...state.items, x]) creates a new array React can detect changed.

Why this matters in interviews

The stale-closure bug is one of the most common real React bugs and one of the most common interview questions, because it tests two things at once: do you understand closures (the JavaScript fundamental), and do you understand that a component re-render is a fresh function call, not a mutation of the same one.