Patterns

// composition over configuration: the prop that was a boolean becomes a child
// configuration: every variation is a prop; the component grows a switch per prop; combinations explode
<Card title="Balance" icon={<Wallet/>} actions={[{ label: 'Top up', onClick }]} footer="Updated 2m ago" variant="elevated" dense />
// composition: the component provides structure; the consumer fills it
<Card variant="elevated">
  <Card.Header icon={<Wallet/>}>Balance</Card.Header>
  <Card.Body><Amount value={balance} /></Card.Body>
  <Card.Actions><Button onClick={topUp}>Top up</Button></Card.Actions>
  <Card.Footer><Relative time={updatedAt} /></Card.Footer>
</Card>
// the second has no "footer as a string or a node?" question, no "actions array shape", no dense prop that half the parts ignore.
// rule of thumb: a prop that takes a node, an array of config objects, or a render function is a slot; make it children of a part instead.
// slots in React are just named children: either compound parts (above) or explicit slot props when order must be fixed:
function Dialog({ title, children, footer }) { return <div role="dialog"><h2>{title}</h2><div>{children}</div><div>{footer}</div></div> }

// render props and hooks: the same inversion, two syntaxes
// render prop: the component owns state and calls a function to render
<MouseTracker>{({ x, y }) => <Cursor x={x} y={y} />}</MouseTracker>
// hook: the state is returned; the consumer renders
const { x, y } = useMouse(); return <Cursor x={x} y={y} />
// hooks replaced render props for sharing logic (no wrapper element, no callback nesting, composable in one function body).
// render props remain for: rendering INTO a position the component controls (a list's row renderer, a table's cell renderer, a virtualiser's item):
<FixedSizeList itemCount={n} itemSize={32}>{({ index, style }) => <Row style={style} item={items[index]} />}</FixedSizeList>
// the row renderer must be stable (useCallback) or the list re-creates every row element per parent render.
// "children as a function" is a render prop by another name. a slot is a render prop that takes a node instead of a function.

// state colocation and the "lift once" rule, as a refactor
// before: the page owns everything; every keystroke in the search box re-renders the page and the table
function Page() { const [query, setQuery] = useState(''); const [sort, setSort] = useState('name'); const rows = useRows()
  return <><Search value={query} onChange={setQuery} /><Table rows={filterSort(rows, query, sort)} sort={sort} onSort={setSort} /></> }
// after: Search owns the draft; the page owns only the committed query (debounced or on submit); sort lives with the table
function Page() { const [query, setQuery] = useState(''); const rows = useRows()
  return <><Search onCommit={setQuery} /><Table rows={rows} query={query} /></> }
function Search({ onCommit }) { const [draft, setDraft] = useState(''); const commit = useDebounced(onCommit, 200); return <input value={draft} onChange={e => { setDraft(e.target.value); commit(e.target.value) }} /> }
function Table({ rows, query }) { const [sort, setSort] = useState('name'); const visible = useMemo(() => filterSort(rows, query, sort), [rows, query, sort]); /* … */ }
// what moved: the keystroke-rate state down into Search (one small render per key); the sort into the only component that uses it;
// the page keeps the one value two siblings need. the Profiler's "why did this render" on Table goes from "parent rendered" per key to nothing.

// headless + polymorphic: a component that renders as whatever element the consumer asks for, keeping its behaviour
function Button({ as: Comp = 'button', ...props }) { return <Comp {...useButtonBehaviour(props)} /> }   // <Button as={Link} to="/x">
// typing `as` correctly is the hard part (polymorphic component types); libraries (Radix's Slot / asChild) avoid the generic by merging onto the child