Anti-Patterns At Scale

// derived state in state: two sources of truth and the effect that fails to keep them equal
const [items, setItems] = useState([])
const [total, setTotal] = useState(0)
useEffect(() => { setTotal(items.reduce((s, i) => s + i.price, 0)) }, [items])     // one render shows items with the OLD total
// fix: const total = items.reduce(…)   (or useMemo for big lists). total cannot be wrong because it does not exist separately.

// the variant with props: copying a prop into state
function Editor({ initialText }) { const [text, setText] = useState(initialText) }   // fine: an initial value, by design
function Label({ text }) { const [t, setT] = useState(text); useEffect(() => setT(text), [text]) }   // wrong: a prop mirrored into state via an effect
// the Label renders the old prop for one frame on every change. just use the prop. if it must be editable, it is an initial value (first form), keyed to reset.

// the variant with "previous value": useEffect(() => { if (prev !== value) … }, [value]) with a ref
// often a derivation (compare in render), sometimes a real "on change" side effect (keep the effect, name it), rarely a job for getDerivedStateFromProps-style
// "adjust state while rendering": if (value !== prevValue) { setPrevValue(value); setDerived(…) } inside render: React re-renders immediately, before commit. no wrong frame.

// the variant with fetching: useEffect(() => { fetch(…).then(setData) }, [id])   → part 8: a query cache

// prop drilling: the honest version, the context version, and the composition version
// drilling: Page → Section → Card → Row → Button, five levels of `onSelect` that only Button uses
<Page onSelect={…}> → <Section onSelect> → <Card onSelect> → <Row onSelect> → <Button onClick={onSelect}>
// not wrong: it is explicit and type-checked. it hurts when the intermediate components are generic layout and the prop is one of twelve.

// context: for a value that is "ambient" to a subtree (the selection, the current user, the theme). the intermediates stop caring.
const Selection = createContext(null); <Selection value={{ selected, select }}>…<Button onClick={() => select(id)} />
// right when the value is dependency-like and changes rarely; wrong when it is per-keystroke state (every consumer renders: part 2)

// composition: pass the component, not the props. the Page renders the Button and gives it to Section as a child.
<Section actions={<Button onClick={onSelect} />}>…</Section>          // Section renders {actions} in its slot; it never sees onSelect
// the intermediates become layout; the data lives where it is used; nothing is drilled. this is the fix most of the time.

// the tell for which you have: if the intermediate components would be the same with or without the prop, it is drilling; compose or context.
// if the intermediates transform the prop, it is data flow; keep it explicit.

// premature memo: what it costs and when it pays
const Row = React.memo(function Row({ item, onSelect }) { return <li onClick={() => onSelect(item.id)}>{item.name}</li> })
// cost per render attempt: shallowEqual over props (a few compares); the hook node for the memo. benefit: skipping Row's render when props are equal.
// Row's render is a few hundred nanoseconds. the compare is a few tens. the saving is real only if props ARE equal (stable onSelect) AND the parent
// re-renders often without changing items. with an inline onSelect at the parent, the compare always fails: pure cost.

// the order of operations for a slow list: 1. is the parent rendering too much? (colocate state). 2. is the list too long for the DOM? (virtualise).
// 3. are the rows' props stable? (useCallback the handlers; useMemo the derived arrays; or enable the Compiler). 4. THEN memo the rows.
// 4 before 1 is the anti-pattern: memo everywhere, parents still re-render everything, and now every component pays a compare.

// useMemo on cheap values: useMemo(() => a + b, [a, b]) costs more than a + b. memo computations that show in a profile, and references that feed memo'd children or deps.
// useCallback on every handler: harmless but noisy; the Compiler makes it moot. without the Compiler: useCallback only for handlers passed to memo'd children or used in deps.