Capstone II: the incremental refactor

Fix the P0 bugs first, because correctness can’t wait behind a redesign — and each is a tiny diff. The derived-state effect ships stale data; the index keys corrupt per-row state. Neither needs the component split to fix, so do them before touching structure. Removing the effect also deletes a useState, a render-after-render cycle, and a dependency-array footgun in one move.

// before — P0: derived state via effect (stale by a frame, fragile by deps)
const [filtered, setFiltered] = useState<Row[]>([]);
useEffect(() => {
  setFiltered(data.filter((r) => r.name.includes(query)));
}, [data, query]);

// after — derive during render: no effect, no second state, never stale
const filtered = data.filter((r) => r.name.includes(query));

// before — P0: index key on a reorderable, stateful list
{rows.map((row, i) => <RowDetail key={i} row={row} />)}
// after — identity follows the row, not the slot
{rows.map((row) => <RowDetail key={row.id} row={row} />)}

Two commits, two closed P0 line items, zero new abstractions. The feature is now correct before it is pretty — and if anything regresses, the revert is one line.

Split the fat context and stabilize its value — but only the part that pressure justifies. The P1 fat context re-renders every consumer on every keystroke because query, selectedId, theme, and data ride one provider value. Split by update frequency, not by tidiness: the volatile query/selectedId go in one context, the stable theme/data in another, so a theme consumer no longer re-renders when you type. And wrap each value in useMemo so a new object literal every render doesn’t defeat the split.

// after — two contexts, split by volatility, each value stabilized
const FilterContext = createContext<FilterCtx | null>(null);
const DataContext = createContext<DataCtx | null>(null);

function DashboardProviders({ children }: { children: React.ReactNode }) {
  const [query, setQuery] = useState("");
  const [selectedId, setSelectedId] = useState<string | null>(null);
  const filter = useMemo(() => ({ query, setQuery, selectedId, setSelectedId }),
    [query, selectedId]);              // volatile — changes per keystroke
  const data = useMemo(() => ({ rows, theme }), [rows, theme]); // stable
  return (
    <DataContext.Provider value={data}>
      <FilterContext.Provider value={filter}>{children}</FilterContext.Provider>
    </DataContext.Provider>
  );
}

Do not split into five contexts because you can — split until the high-frequency updates stop touching the low-frequency consumers. That’s where the pressure ends, so that’s where the change ends.

Decompose the god component with composition + extracted custom hooks — concern by concern, not in one rewrite. The P1 god component owns fetching, filtering, sorting, paginating, selection, and rendering. Pull one concern at a time: extract the data lifecycle into useDashboardData() (a custom hook), then carve the render into <Toolbar>, <DataTable>, and <Detail>. After each extraction the app still runs — you’re moving lines into a named home, not changing behaviour.

// extract the data concern into a hook (testable, reusable, one job)
function useDashboardData(query: string, sortKey: keyof Row) {
  const rows = use(fetchRows());            // React 19: read the promise
  return useMemo(
    () => sortRows(rows.filter((r) => r.name.includes(query)), sortKey),
    [rows, query, sortKey],
  );
}

// the god component shrinks to composition: each child owns one concern
function Dashboard() {
  return (
    <DashboardProviders>
      <Toolbar />
      <DataTable />
      <Detail />
    </DashboardProviders>
  );
}

Composition also dissolves the P2 prop drilling for free: once RowActions reads selectedId from FilterContext (or sits as a direct child of the component that owns it), the four pass-through hops vanish. You didn’t add a pattern for drilling — you let the structural fix subsume it.

Colocate or lift each piece of state to the level that owns it — then wrap the async edge in Suspense under an Error Boundary. With concerns separated, state finds its level: a row’s open/closed flag colocates inside <RowDetail> (nothing above it cares), while query/selectedId stay lifted to the provider because two siblings share them. State that nobody shares does not belong in the provider. Finally, the data fetch is the one async boundary, so it gets a <Suspense> fallback and an Error Boundary above it — co-located, because a boundary with no error UI is half a boundary.

// state at the right level + the async boundary made explicit
function DataTable() {
  return (
    <ErrorBoundary fallback={<TableError />}>
      <Suspense fallback={<TableSkeleton />}>
        <DataRows />          {/* useDashboardData() suspends in here */}
      </Suspense>
    </ErrorBoundary>
  );
}

function RowDetail({ row }: { row: Row }) {
  const [open, setOpen] = useState(false); // colocated — only this row cares
  return <div onClick={() => setOpen((o) => !o)}>{open && <Body row={row} />}</div>;
}

Five commits in, the inventory is closed: each P0 bug gone, the context split, the god component composed, state at its level, the async edge bounded — and the diff reads as a sequence, not an explosion.