A React list renders each row with onClick={() => onSelect(item.id)}, creating one closure per row on every render. What are the alternatives that avoid that, and what do you trade for them?

## What the per-row closure actually costs ```jsx {items.map(item => ( <li key={item.id}> <button onClick={() => onSelect(item.id)}>{item.name}</button> </li> ))} ``` Every render of the list allocates one closure per row. For a hundred rows that is a hundred short-lived function objects, which on its own is not a problem worth solving — the elements, the props objects and the strings around them cost more. The cost that can matter is identity. If `Row` is wrapped in `React.memo` so that unrelated parent state (a search box, a hover flag) does not re-render every row, the fresh `onClick` prop defeats the comparison on every row, every time. The memo does no work except comparing. That is the situation where the question is worth asking at all. ## Option 1: let the row bind the argument The parent stops constructing the per-item closure and hands down two stable things: the item it already passes, and one callback whose identity does not change. ```jsx const Row = memo(function Row({ item, onSelect }) { return <button onClick={() => onSelect(item.id)}>{item.name}</button>; }); function List({ items, select }) { const onSelect = useCallback(id => select(id), [select]); return items.map(item => <Row key={item.id} item={item} onSelect={onSelect} />); } ``` The closure still exists — it now lives inside `Row` and is recreated whenever `Row` renders, which is precisely when it should be. From the memo comparison's point of view, `Row` receives the same `item` object and the same `onSelect` function, so a parent re-render bails out. This is the idiomatic React answer because it keeps the typed object reference, keeps the code readable, and puts the memoization boundary where the render actually is. Its requirement is that `onSelect` really is stable: if the parent recreates `select` every render, wrapping it in `useCallback` with `[select]` stabilises nothing. ## Option 2: one handler plus a data attribute The alternative is to give up per-row functions entirely. One handler, defined once, reads the identifier off the element that was clicked: ```jsx function List({ items, select }) { const onClick = useCallback(e => select(e.currentTarget.dataset.id), [select]); return items.map(item => ( <button key={item.id} data-id={item.id} onClick={onClick}>{item.name}</button> )); } ``` Now every row shares one function object, so identity is stable by construction with no `useCallback` per row and no closure allocation at all. What you trade: - **Everything becomes a string.** Attribute values are text, so a numeric id arrives as `"42"` and needs converting, and a composite key needs encoding and decoding. - **You lose the reference.** The closure could capture the whole `item`; the attribute can only carry an identifier, so the handler has to look the item back up in the source array. - **Type safety evaporates.** In TypeScript the closure form checks the argument at compile time; a value pulled out of a dataset is `string | undefined` and any structure you claim about it is an assertion. - **You must be careful which element you read from.** Reading from the element the handler is attached to is well defined; reading from whatever was actually clicked is not, because a click can land on an inner span. ## Choosing between them Ask what is really under pressure. If the list is a normal page of rows and nothing is memoized, do nothing: the inline closure is the clearest code and its cost is noise. If rows are memoized and re-render on unrelated parent state, push the binding into the row — you keep types and readability and you fix the comparison. Reserve the data-attribute form for genuinely large or hot lists where you want a single handler shared across thousands of elements and are willing to accept string identifiers. The wrong answer is to reach straight for `useCallback` inside the `map` callback — hooks cannot be called in a loop at all, so the reflex does not even compile as a rule-abiding component. That constraint alone is a useful thing to say out loud: per-item stability has to come from the child's own render or from sharing one handler, never from memoizing inside the loop.