Capstone III: measure before and after

Measure render behaviour with the React Profiler, not by eye — count commits and what re-rendered in each. Before/after, record the same interaction (type one character into the filter) under the Profiler. The numbers that matter: how many components committed, and which. Before, a keystroke re-rendered the whole tree because state lived too high and one fat context fed everyone. After, deriving filtered during render and splitting context means a keystroke commits only the Toolbar input and the DataTable — Detail and theme consumers don’t.

// before — Profiler on one keystroke: ~14 components commit (whole feature)
// after  — Profiler on one keystroke: 2 commit (Toolbar input + DataTable)
//
// the cause, stated in UI = f(state) terms:
// 'filtered' is now f(data, query) computed in render, and query lives
// next to the input — so changing query only re-runs f for the parts that read it
const filtered = data.filter((r) => r.name.includes(query)); // no effect, no second state

This is the headline metric. “Feels faster” is not a result; “14 commits → 2 commits on a keystroke, captured in the Profiler” is.

Measure changeability as drilling depth and change-locality — refactoring is supposed to make the next change cheap. Two countable signals. First, prop-drilling depth: the onSelect callback that threaded Dashboard → Table → TableBody → Row → RowActions (four hops) now reaches its consumer directly via context or lifted markup — depth 4 → 0. Second, and the real prize, change-locality: the target change the feature was built to absorb now touches one place.

// "add a 'status' column" — BEFORE: edit the type, the <th> row, the <td>
// map, the sort switch, AND the fetch shape, scattered across the god component.
//
// AFTER: columns are data, rendering is f(columns), so it's one local edit:
const columns: Column<Row>[] = [
  { key: "name", header: "Name" },
  { key: "email", header: "Email" },
  { key: "status", header: "Status" }, // <- the whole change
];
// <DataTable columns={columns} rows={filtered} /> renders f(columns, rows)

A change that was five scattered edits is now one. That delta — not the line count of the diff — is what you report.

Prove the correctness win the same way you proved the perf win: show the derived-state bug is structurally gone, not just unobserved. The P0 smell from part 1 was a staleness bug — filtered copied from data + query by an effect, stale by a frame and fragile to a missed dependency. “I didn’t see it anymore” is not proof; the effect could still misfire. The proof is structural: there is no second state and no effect, so there is no window in which filtered can disagree with data and query.

// before — two sources of truth, reconciled late by an effect (stale-by-a-frame)
const [filtered, setFiltered] = useState<Row[]>([]);
useEffect(() => { setFiltered(data.filter((r) => r.name.includes(query))); }, [data, query]);

// after — one source of truth; the bug class cannot exist because there is no copy
const filtered = data.filter((r) => r.name.includes(query));

This is UI = f(state) enforced: derive, don’t duplicate. The win is reported as “bug class eliminated” — the staleness can’t recur because the state it lived in is gone.

Know when to STOP: a refactor has a point of payoff, and going past it is risk without return. You closed every inventory line item; the Profiler is green; the target change is local; the bug is gone. The junior temptation now is to keep going — memoize every component, extract three more hooks, make DataTable infinitely generic for columns that don’t exist yet. That is not seniority, it’s the over-engineering this whole track warns against, now wearing a refactor’s clothes. Each extra abstraction adds indirection and a chance to introduce a regression, for a speculative future change that may never arrive.

// STOP signal: the next "improvement" optimizes a change nobody has asked for.
// - memo() on a component the Profiler shows commits twice a session → no payoff
// - a generic <DataTable> plugin system for one table → YAGNI, pure cost
// good enough (measured, local, correct) beats perfect (speculative, risky)

The stopping rule is the cost-of-change lens applied to the refactor itself: stop when the next edit’s cost no longer exceeds the cost (and risk) of the abstraction that would reduce it. Past that line, you are spending to make an imaginary change cheaper.