useRef: mutable values & DOM refs

useRef(initial) gives you a plain object { current: initial }. React keeps the same object across every render, so ref.current is a stable place to stash a value — and changing it does not trigger a re-render.

function LikeButton() {
  const clicks = useRef(0);

  function handleClick() {
    clicks.current += 1; // ✅ written in an event handler: no re-render
    sendAnalytics("like", clicks.current);
  }

  return <button onClick={handleClick}>Like</button>;
}

Contrast with a normal let clicks = 0 inside the component: that resets to 0 on every render. ref.current persists. Contrast with useState: state also persists, but writing to it schedules a render. A ref writes silently.

Reach for a ref when you need to remember something between renders but the UI doesn't need to react to it — a timer id, a previous value, a "did this already run" flag.

State and refs both persist across renders. The one question that decides between them: when this value changes, should the screen update?

• Yes → useState. The value is shown, or drives what's shown. Writing it re-renders.
• No → useRef. The value is bookkeeping the render doesn't read. Writing it is silent.

function Stopwatch() {
  const [elapsed, setElapsed] = useState(0); // shown → state
  const intervalId = useRef(null);           // plumbing → ref

  function start() {
    clearInterval(intervalId.current); // a second Start must not leave the first one running
    intervalId.current = setInterval(() => setElapsed((e) => e + 1), 1000);
  }
  function stop() {
    clearInterval(intervalId.current); // read it back later, no render needed
  }

  return (
    <>
      <p>{elapsed}s</p>
      <button onClick={start}>Start</button>
      <button onClick={stop}>Stop</button>
    </>
  );
}

The elapsed time is on screen, so it's state. The interval id is only there so stop() can clear it — nothing renders it — so it's a ref. Putting the id in state would cause a pointless re-render; putting elapsed in a ref would freeze the display, since mutating .current never tells React to repaint.

A callback created in one render closes over that render's variables. If it runs much later — inside a long-lived interval, a subscription, an event listener you attach once — it sees the old values. Two bad options come first to mind: add onMessage to the effect's deps and reconnect the socket every time the parent passes a new function, or leave it out and call a stale onMessage forever.

Since React 19.2, the tool for this is useEffectEvent. An Effect Event always sees the latest props and state, and it is not a dependency:

function ChatRoom({ roomId, onMessage }) {
  const onReceive = useEffectEvent((m) => onMessage(m)); // always the newest onMessage

  useEffect(() => {
    const socket = connect(roomId);
    socket.on("message", (m) => onReceive(m));
    return () => socket.close();
  }, [roomId]); // ✅ reconnects for a new room, not for a new onMessage
}

Effect Events have rules: call them only from inside effects (including callbacks the effect sets up, like this listener), never during render, and never pass them to other components or hooks. Don't use one to drop a dependency the effect really should react to: roomId stays in the array.