In React 19, what may a callback ref return, and how does returning it change the way React detaches the ref?

## Two shapes for a ref prop Anywhere React accepts `ref`, you may pass either of two things: 1. **A ref object** — what `useRef` returns. React writes the element into its `current` property and writes `null` back on detach. You do not get a notification; you just read the box later. 2. **A callback** — a function React calls *with* the element. This is the shape to choose when attachment itself is the event you care about, because it runs at the moment the node becomes available rather than leaving you to check later. ## The old two-call protocol Before React 19, a callback ref was called twice around its lifetime: once with the node, once with `null` when the element went away. Every callback that set something up therefore carried a branch: ```jsx <div ref={(node) => { if (node) { resizeObserver.observe(node); } else { resizeObserver.disconnect(); } }} /> ``` It worked, but it read badly. The setup and the teardown sat in the same function with no shared scope for whatever the setup produced, so anything the cleanup needed had to be hoisted into a ref or a module variable. ## The React 19 cleanup return React 19 lets the callback return a function, and treats that returned function as the cleanup: ```jsx <div ref={(node) => { const observer = new ResizeObserver(handleResize); observer.observe(node); return () => observer.disconnect(); }} /> ``` The teardown now closes over exactly what the setup created, which is the same ergonomic win `useEffect` has always had. Two behavioural points follow: - **The null call is skipped.** If you return a cleanup, React will not invoke your callback again with `null`. That is deliberate: the two mechanisms would otherwise both fire and double-tear-down. - **The old protocol still works.** If you return nothing, React keeps calling with `null` on detach, so existing callbacks are untouched. ## The implicit-return trap The most common React 19 upgrade snag is a one-liner that was never meant to return anything: ```jsx <input ref={(el) => (inputRef.current = el)} /> ``` An arrow with a concise body returns the value of its expression, and an assignment evaluates to the assigned value — so this returns the element. React 19 expects a returned value to be a cleanup function, and the React 19 types now reject the pattern to stop you shipping it. The fix is purely syntactic: wrap the body in braces so the arrow returns `undefined`. ```jsx <input ref={(el) => { inputRef.current = el; }} /> ``` Worth internalising as a general lesson about concise arrow bodies in any position where the return value has acquired a meaning. ## When to prefer a callback over a ref object Reach for a callback when you need to *react* to attachment rather than merely hold the node: wiring an observer, registering a node in a map keyed by id, measuring on attach, handing a node to a third-party constructor. Reach for a `useRef` object when you only need to reach the node later from a handler — it is simpler and there is nothing to clean up. ## Interaction with useImperativeHandle The two compose without special handling. A child that installs a handle with `useImperativeHandle` does not care whether the parent passed an object ref or a callback; React resolves the handle to whichever shape came in, so a parent's callback ref receives the handle object rather than a DOM node.