Lesson 10 of 80

useRef

Q: What is useRef for, and how does it differ from useState?

A strong answer covers: useRef returns a mutable object ({ current }) that persists across renders without ever causing a re-render when mutated; useState's setter schedules a re-render; refs are for values the UI doesn't need to reflect (timers, DOM nodes, mutable instance-like data); Common uses: accessing a DOM node imperatively, and storing a mutable value (like an interval id) needed across renders.

A mutable box that survives between renders, exactly like useState — except changing it never triggers a re-render. That one difference is the whole lesson.

13 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 2

Does calling `myRef.current = 5` trigger a re-render, the way `setState(5)` would?

No — refs are mutable and changing .current never schedules a re-renderYes — any change tracked by a hook triggers a re-renderOnly if the ref is attached to a DOM element via the ref attribute

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 useRef

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

What is useRef for, and how does it differ from useState?

A strong answer covers

useRef returns a mutable object ({ current }) that persists across renders without ever causing a re-render when mutated
useState's setter schedules a re-render; refs are for values the UI doesn't need to reflect (timers, DOM nodes, mutable instance-like data)
Common uses: accessing a DOM node imperatively, and storing a mutable value (like an interval id) needed across renders

Likely follow-ups

Why is it risky to read or write a ref during render instead of in an effect or event handler?
How would you use a ref to fix a stale-closure bug where you need the 'latest' value inside a long-lived callback?
Is ref.current guaranteed to be set on the very first render?

Practice these with the AI interviewer →

The plain-language idea

useRef(initialValue) returns a plain object: { current: initialValue }. That object is the same object across every render of the component — React doesn't recreate it. You can read and write .current freely, and it behaves nothing like state:

function Stopwatch() {
  const intervalId = useRef(null);   // survives renders, mutating it doesn't re-render
  const [running, setRunning] = useState(false);

  function start() {
    intervalId.current = setInterval(() => console.log("tick"), 1000);
    setRunning(true);
  }
  function stop() {
    clearInterval(intervalId.current);
    setRunning(false);
  }
  // ...
}

intervalId needs to survive between renders (so stop can clear the same interval start created) but has no business triggering a re-render when it changes — nothing on screen depends on its value. That's exactly what useRef is for; useState would work but would cause pointless extra renders.

useRef: a mutable box that survives renders quietlyStep 1 of 3

const ref = useRef(initialValue) — a mutable box that persists across renders.

What people usually miss

Watch out

Reading or writing .current during render is a footgun. Refs are meant for effects and event handlers, which run after render — mutating a ref during render can silently produce a value that's one render behind, since the read doesn't trigger a re-render to reconcile it.
A ref is the direct fix for the useState stale-closure trap when you specifically need the latest value inside a long-lived closure (like a setInterval callback) without wanting a re-render on every tick.
ref.current starts as null for DOM refs until after the first render commits — accessing inputRef.current.focus() during the render itself, before the DOM exists, throws.

Why this matters in interviews

"When would you use useRef instead of useState?" is a direct test of whether you understand why two hooks that both "hold a value across renders" exist — the answer is entirely about whether a change should cause a re-render.