A React component renders a list of rows and needs programmatic access to each row's DOM node. How do you collect those refs, and what has to happen when a row is removed?

## Why the obvious approaches fail **One `useRef` per row.** Hooks must be called unconditionally, in the same order, on every render. A list whose length changes cannot call a hook per item, so `items.map(item => useRef(null))` is illegal and the lint rule rejects it. **An array indexed by position.** `refs.current[index] = node` compiles and appears to work, until the list reorders or an item is removed from the middle. Now index 2 holds the node that used to be item C and is currently item D, or a hole where a removed item was. The array's index is not the item's identity, and any code that later looks up "the node for item C" gets the wrong element. ## The shape that works One ref holding a `Map`, keyed by whatever identifies the item in your data, plus a callback ref per row: ```jsx function Rows({ items }) { const nodes = useRef(new Map()); const scrollTo = (id) => nodes.current.get(id)?.scrollIntoView(); return ( <ul> {items.map((item) => ( <li key={item.id} ref={(node) => { nodes.current.set(item.id, node); return () => nodes.current.delete(item.id); }} > {item.label} </li> ))} </ul> ); } ``` The cleanup return is the React 19 form. Targeting React 18, the same callback branches on the argument: ```jsx ref={(node) => { if (node) nodes.current.set(item.id, node); else nodes.current.delete(item.id); }} ``` A `Map` is preferred over a plain object because ids are frequently numbers or non-string values, and because `delete`, `get` and iteration are explicit operations rather than prototype-adjacent property fiddling. ## Why the delete is the whole question An interviewer asking this is usually watching for whether you handle detach at all. **Memory.** A removed `<li>` that is still referenced from your `Map` cannot be garbage collected, and neither can its subtree or any listeners hanging off it. In a long-lived virtualised or paginated list, a map that only grows is a genuine leak that shows up as steadily rising detached-node counts in a heap snapshot. **Correctness.** Code that iterates the map to measure or focus rows will touch nodes that are no longer in the document. Imperative calls against them do nothing visible, which produces the worst kind of bug — silently absent behaviour rather than an error. **Staleness.** If a row unmounts and a *different* row later mounts with the same key, an entry that was never cleaned up may or may not be overwritten depending on ordering. Explicit deletion makes the map's contents exactly the set of currently-attached rows, which is the invariant everything else relies on. If you want the map to hold entries only as long as the nodes are alive regardless, `WeakMap` is the wrong direction here — it is keyed by object, and your keys are ids — so explicit deletion in the cleanup is the mechanism. ## The identity churn caveat The callback in the example above is inline, so it is a new function on every render, and React therefore detaches and re-attaches every row's ref on every render of the list: `delete` then `set`. For a `Map` write that is cheap and self-correcting, and it is the common production shape. If the callback does something more expensive, lift each row into its own component and stabilise the callback there with `useCallback` keyed on the item's id — which is the more maintainable structure for a nontrivial row anyway. ## Where this shows up Roving-focus keyboard navigation across a list, scrolling a selected item into view, driving an imperative animation across items, and anything that needs "give me the element for this record". In all of these the lookup is by record identity, which is the reason the `Map` is keyed by id and the reason the array-by-index version keeps producing bugs that only appear after a reorder. ## What to say out loud Name the three constraints in order: hooks cannot be called per item, so one container ref; nodes must be findable by item identity, so a `Map` keyed by id; and attachment is a pair, so the detach branch must remove the entry. Everything else is detail.