useRef — DOM Access & Persistent Values

🎓 What You Will Learn

DOM access: reach a real DOM node with ref — focus, scroll, measure
Persistent values: store a value across renders without triggering one
The interval/timer pattern: holding a timer ID in a ref instead of state
Tracking previous values: the usePrevious() custom hook
useRef vs useState: a clear rule for which one to reach for
Common mistakes: reading refs during render, expecting them to trigger updates

What useRef Actually Gives You

useRef(initialValue) returns a plain object: { current: initialValue }. That object is the same object across every render of the component — React never recreates it. Two things follow from that: you can mutate .current freely, and doing so does not trigger a re-render.

That makes useRef useful for exactly two jobs: holding a reference to a real DOM node, and holding any other mutable value you need to persist but don't want to cause renders (a timer ID, a previous value, a flag).

Accessing the DOM Directly

Pass a ref to an element's ref prop, and React fills in .current with the actual DOM node once it mounts. From there you can call any native DOM method — .focus(), .scrollIntoView(), read .value.

Note the optional chaining: inputRef.current?.focus(). .current starts as null before the first render completes, so always guard against that.

Persistent Values That Don't Trigger Renders

A classic case: storing a setInterval ID so you can clear it later. If you put that ID in useState, every tick where you save it would trigger an unnecessary re-render. A ref holds it silently.

Always clean up. Clear the interval both when the user clicks "Stop" and in a useEffect cleanup function, so it doesn't keep running after the component unmounts.

Mutating .current Doesn't Re-render

This is the core mental model to internalize: changing ref.current is invisible to React. The component only re-renders because of clicks (a real state update) — the render count itself is just along for the ride.

This component has rendered 1 time(s) — read from a ref that updates during render but never causes one.

Tracking a Previous Value

A common need: comparing the current value of a prop or state to what it was last render. There's no built-in usePrevious hook, but it's a perfect fit for useRef + useEffect.

Now: 0 · Previous: —

Why this works: the useEffect runs after the render, so during render ref.current still holds last render's value. Only after painting does the effect update it to the new one.

useRef vs. useState

	useState	useRef
Triggers a re-render on change?	Yes	No
Value persists across renders?	Yes	Yes
Read during render?	Always current	Current, but stale-looking after an update this render
Use for UI that must update	✅	❌
Use for DOM nodes, timers, previous values	❌	✅

Common Mistakes

1Expecting a ref update to re-render the UI

mistake-no-rerender.jsx

// ❌ BAD: the displayed count never updates — mutating a ref doesn't re-render
const countRef = useRef(0);
const increment = () => { countRef.current += 1; };
return <button onClick={increment}>{countRef.current}</button>;

// ✅ GOOD: use state for anything that should show up on screen
const [count, setCount] = useState(0);
return <button onClick={() => setCount(c => c + 1)}>{count}</button>;

2Reading ref.current before it's attached

mistake-null-ref.jsx

// ❌ BAD: .current is null on first render, before the DOM node exists
useEffect(() => {
  inputRef.current.focus(); // may crash if this runs too early
}, []);

// ✅ GOOD: guard with optional chaining, or trust useEffect's timing
useEffect(() => {
  inputRef.current?.focus(); // runs after mount, .current is set by then
}, []);

3Using a ref for values the UI must reflect

mistake-wrong-tool.jsx

// ❌ BAD: form input value stored in a ref — typing shows nothing on screen
const nameRef = useRef("");
return <input onChange={(e) => (nameRef.current = e.target.value)} />;

// ✅ GOOD: controlled inputs need state, not a ref
const [name, setName] = useState("");
return <input value={name} onChange={(e) => setName(e.target.value)} />;

Best Practices

✅Use refs for DOM access — focus, scroll, measuring, integrating non-React libraries

✅Use refs for values the UI doesn't display — timer IDs, previous values, render counts

✅Guard with optional chaining — ref.current?.method() — before the DOM mounts

✅Never use a ref for anything the JSX renders — that's what state is for

✅Clean up timers/subscriptions stored in refs inside a useEffect cleanup

Pattern Reference

Pattern	Use Case
useRef(null) + ref={...}	Access a DOM node directly
useRef(value) mutated in handlers	Store a timer ID, a flag, a cache — no re-render needed
useRef + useEffect	Track the previous value of a prop or state
useRef(0), current += 1 in render	Count renders for debugging (dev only)

Practice Project

Build a small video player control bar that:

Uses a ref to hold the <video> element and calls .play() / .pause() directly
Uses a ref to store a setInterval that polls currentTime for the progress bar
Uses usePrevious() to detect when playback state changed, and log it
Cleans up the interval in a useEffect cleanup when the component unmounts

What's Next?

🚀 Next Learning Topics:

Custom Hooks: extract usePrevious and similar patterns into a shared library
useEffect: revisit cleanup timing now that refs are in the picture
useMemo / React.memo: the other tools for controlling what causes a render
React Hooks Deep Dive: see how all the hooks fit together

Keep practicing! 💪 Once "does this need to re-render the UI?" becomes your instinct for choosing between useState and useRef, a whole category of unnecessary re-renders disappears from your components.