Capstone I: the pattern-smell inventory

Smell one — the god component: one component owning many unrelated concerns, so it has many reasons to change and one giant render. Scan for a single component that fetches, filters, sorts, paginates, holds selection, and renders. That’s not “a big component”, it’s a coupling magnet: any state change re-renders all of it, and any feature change risks all of it.

// smell: Dashboard owns 7 concerns and ~500 lines
function Dashboard() {
  const [data, setData] = useState<Row[]>([]);
  const [query, setQuery] = useState("");
  const [sortKey, setSortKey] = useState<keyof Row>("name");
  const [page, setPage] = useState(0);
  const [selectedId, setSelectedId] = useState<string | null>(null);
  // ...fetch effect, filter, sort, paginate, render table + toolbar + detail
}

Locate it precisely: “concerns owned” is the metric. Seven here. The fix family is composition + custom hooks, but you do not apply it yet — you record it.

Smell two — prop drilling: passing data through components that don’t use it, just to reach a deep consumer. Follow one prop. If onSelect or currentUser is declared in Dashboard, accepted by Table, forwarded by TableBody, forwarded by Row, and only used in RowActions, every intermediate component is change-coupled to a prop it doesn’t care about — and re-renders when it changes.

// smell: onSelect threaded through 4 components that don't use it
<Table onSelect={onSelect}>          {/* passes down */}
  <TableBody onSelect={onSelect}>    {/* passes down */}
    <Row onSelect={onSelect}>        {/* passes down */}
      <RowActions onSelect={onSelect} /> {/* finally uses it */}

The fix family is context or composition (lift markup so the consumer is a direct child). Record depth: four hops here. Drilling depth is your change-cost signal.

Smell three — effect-derived state: an effect that copies or computes one piece of state from another, creating a latent staleness bug. This is the highest-severity smell because it isn’t just slow, it’s wrong. An effect that writes filtered from data + query runs after render, so there’s a frame where filtered is stale, and any missed dependency makes it permanently stale.

// smell: 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]); // forget one dep → permanently stale

The fix is to derive during render (const filtered = data.filter(...)), no effect, no second state. Rank this near the top: it’s a correctness bug, not a performance one.

Smell four — fat context: one context holding many unrelated values, so every consumer re-renders when any single value changes. A DashboardContext that bundles query, selectedId, theme, and data means a component reading only theme re-renders on every keystroke that changes query. Context updates are all-or-nothing per provider value.

// smell: unrelated values in one context → keystroke re-renders theme consumers
const DashboardContext = createContext<{
  query: string; selectedId: string | null; theme: Theme; data: Row[];
} | null>(null);

The fix family is split contexts (or move volatile state out of context entirely). Record the consumer count and update frequency: that product is your wasted-render estimate.

Smell five — index keys on a reorderable list: key={i} ties React’s identity to position, not the item, so reordering or deleting corrupts per-row state. This is a latent bug, not just a lint warning: when rows carry local state (an open/closed detail, an input draft), index keys make that state follow the slot, not the row.

// smell: key is the index, but rows reorder and carry open/closed state
{rows.map((row, i) => <RowDetail key={i} row={row} />)} // delete row 0 → row 1's state shows on row 0

The fix is a stable id key (key={row.id}). Severity depends on whether the list reorders and whether rows hold state — here both are true, so it’s a real bug, not a nit. Record that context, not just the line.