Капстоун III: измерь до и после

Измеряй поведение рендера через React Profiler, а не на глаз — считай коммиты и что перерисовалось в каждом. До/после запиши одно и то же взаимодействие (введи один символ в фильтр) под Profiler. Важны числа: сколько компонентов закоммитилось и какие. До нажатие клавиши перерисовывало всё дерево, потому что состояние жило слишком высоко и один жирный контекст кормил всех. После, выводя filtered во время рендера и разделив контекст, нажатие коммитит только поле Toolbar и DataTable — потребители Detail и theme нет.

// до — Profiler на одно нажатие: коммитится ~14 компонентов (вся фича)
// после — Profiler на одно нажатие: коммитится 2 (поле Toolbar + DataTable)
//
// причина, в терминах UI = f(state):
// 'filtered' теперь f(data, query), вычисляемая в рендере, и query живёт
// рядом с полем ввода — так что смена query перезапускает f только для тех частей, что её читают
const filtered = data.filter((r) => r.name.includes(query)); // ни эффекта, ни второго состояния

Это заголовочная метрика. «Ощущается быстрее» — не результат; «14 коммитов → 2 коммита на нажатие, зафиксировано в Profiler» — результат.

Измеряй изменяемость как глубину проброса и локальность изменения — рефакторинг должен делать следующее изменение дешёвым. Два считаемых сигнала. Первый — глубина проброса пропсов: коллбэк onSelect, который пронизывал Dashboard → Table → TableBody → Row → RowActions (четыре прыжка), теперь достигает своего потребителя напрямую через контекст или поднятую разметку — глубина 4 → 0. Второй и главный приз — локальность изменения: целевое изменение, под которое фича строилась, теперь трогает одно место.

// «добавить колонку 'status'» — ДО: правишь тип, строку <th>, map <td>,
// switch сортировки И форму fetch, разбросанные по божественному компоненту.
//
// ПОСЛЕ: колонки — это данные, рендеринг — f(columns), так что это одна локальная правка:
const columns: Column<Row>[] = [
  { key: "name", header: "Name" },
  { key: "email", header: "Email" },
  { key: "status", header: "Status" }, // <- всё изменение целиком
];
// <DataTable columns={columns} rows={filtered} /> рендерит f(columns, rows)

Изменение, которое было пятью разбросанными правками, теперь одно. Именно эту дельту — а не число строк диффа — ты докладываешь.

Докажи выигрыш в корректности так же, как доказал выигрыш в перформансе: покажи, что баг производного состояния ушёл структурно, а не просто перестал наблюдаться. P0-запах из части 1 был багом устаревания — filtered копировалось из data + query эффектом, устаревало на кадр и было хрупким к пропущенной зависимости. «Я его больше не видел» — не доказательство; эффект всё ещё мог сработать не вовремя. Доказательство структурно: нет второго состояния и нет эффекта, поэтому нет окна, в котором filtered может разойтись с data и query.

// до — два источника истины, поздно сводимые эффектом (устаревание на кадр)
const [filtered, setFiltered] = useState<Row[]>([]);
useEffect(() => { setFiltered(data.filter((r) => r.name.includes(query))); }, [data, query]);

// после — один источник истины; класс бага не может существовать, потому что нет копии
const filtered = data.filter((r) => r.name.includes(query));

Это UI = f(state) в действии: выводи, не дублируй. Выигрыш докладывается как «класс бага устранён» — устаревание не может повториться, потому что состояния, в котором оно жило, больше нет.

Знай, когда ОСТАНОВИТЬСЯ: у рефакторинга есть точка окупаемости, и заходить за неё — это риск без отдачи. Ты закрыл каждый пункт инвентаризации; Profiler зелёный; целевое изменение локально; баг ушёл. Джуниорский соблазн сейчас — продолжать: мемоизировать каждый компонент, вынести ещё три хука, сделать DataTable бесконечно обобщённым под колонки, которых ещё нет. Это не seniority, это то самое переусложнение, от которого весь трек предостерегает, теперь в одежде рефакторинга. Каждая лишняя абстракция добавляет косвенность и шанс внести регресс — ради спекулятивного будущего изменения, которое может никогда не наступить.

// сигнал СТОП: следующее «улучшение» оптимизирует изменение, которого никто не просил.
// - memo() на компоненте, который Profiler коммитит дважды за сессию → нет окупаемости
// - универсальная плагин-система <DataTable> ради одной таблицы → YAGNI, чистая стоимость
// достаточно хорошо (измерено, локально, корректно) бьёт идеально (спекулятивно, рискованно)

Правило остановки — это линза стоимости изменения, применённая к самому рефакторингу: остановись, когда стоимость следующей правки больше не превышает стоимость (и риск) абстракции, которая её сократила бы. За этой чертой ты тратишь, чтобы удешевить воображаемое изменение.