A teammate argues that filtering and sorting a 5,000-item list on every React render is wasteful and wants to keep the sorted result in useState, updated by an effect whenever the inputs change. How do you respond, and when is useMemo the right tool instead?

## Answer the correctness question before the performance one A derived value computed during render cannot be stale, because it is rebuilt from its inputs every time. Moving it into state converts a structurally-correct design into one that needs synchronisation. Before discussing speed, that trade has to be named: the proposal buys nothing and sells the invariant. Walk through what the effect version actually does when `query` changes: 1. Render with the new `query` but the *old* stored list. 2. Commit; the browser may paint that mismatched frame. 3. The effect runs and sorts — the same work the render-time version does. 4. `setState` schedules a second render, which commits the correct list. So: the same sort, an extra render pass, an extra commit, and a visible window where the displayed rows do not match the filter. Add the maintenance hazards of any mirror — a forgotten dependency freezes the list, a second writer races the effect — and it is worse on every axis, including the one it was proposed to improve. ## Then ask whether the cost is real "5,000 items" sounds expensive and usually is not. A `filter` plus `sort` over 5,000 plain objects is on the order of a millisecond or two on a modern machine. Rendering 5,000 rows into the DOM is not — that is tens of milliseconds of reconciliation, layout and paint. Measure before optimising: record an interaction in the React DevTools Profiler and see which component owns the time, or bracket the derivation with `performance.now()` and look at real numbers on the slowest device you support. Most of the time the answer is that the derivation is noise and the render volume is the problem, which points at rendering fewer rows (windowing) or splitting the component so the expensive subtree does not re-render — not at caching the array. ## When `useMemo` is the right tool If the profile says the derivation itself dominates, `useMemo` is what you want: ```jsx const visible = useMemo( () => rows.filter((r) => r.name.includes(query)) .sort((a, b) => a.name.localeCompare(b.name)), [rows, query], ); ``` The critical difference from the `useState` proposal: this is still derived state. The value is produced *during* the render that needs it, so there is no stale frame and no extra render; the inputs are declared in one place; and there is no second writer. `useMemo` is a cache over a pure computation, not a copy of a fact. Two caveats worth stating unprompted. First, `useMemo` is a performance hint, not a semantic guarantee — React is allowed to throw cached values away and recompute, so code must stay correct if the function runs on every render. Never put a side effect, or an identity something depends on staying stable forever, inside it. Second, memoisation is not free: it costs a dependency comparison and retains the previous result in memory, and if the dependencies change on every render it is pure overhead. A second legitimate reason to memoise a derived array is *referential stability* rather than raw compute — a new array identity each render defeats downstream bail-outs — but that is a rendering-cost argument, and it should also be made from a profile rather than by reflex. ## React 19 and the compiler With the React Compiler (`babel-plugin-react-compiler`) enabled, this class of memoisation is inserted at build time from the component's data flow, and hand-written `useMemo` for ordinary derived values becomes largely unnecessary. That reinforces the argument rather than weakening it: the compiler can memoise a value derived during render because it can see the dependency graph; it can do nothing for a copy you have hidden in `useState` behind an effect. Writing plainly derived code keeps the automatic option open. ## When precomputing genuinely belongs elsewhere There are cases where the sorted list should not be computed in the component at all — the server can return it ordered, or the ordering is a query the data layer should own. That is a different conversation from `useState` versus `useMemo`, and it is often the best answer for large datasets: don't ship 5,000 rows to the client to sort them. ## How to close the discussion "Derived by default; measure; memoise the derivation if the measurement says so; never mirror it into state." The proposal is not a smaller version of `useMemo` — it is a different thing that happens to sound similar, and the difference is that one keeps a single source of truth and the other does not.