Капстоун II: инкрементальный рефакторинг

Сначала исправь P0-баги, потому что корректность не может ждать за редизайном — и каждый из них крошечный дифф. Эффект производного состояния отдаёт устаревшие данные; index-ключи портят состояние по строкам. Ни один из них не требует разбивки компонента, так что делай их до того, как трогать структуру. Удаление эффекта заодно удаляет useState, цикл «рендер-после-рендера» и грабли с массивом зависимостей — одним движением.

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

// after — выводим во время рендера: ни эффекта, ни второго состояния, никогда не устаревает
const filtered = data.filter((r) => r.name.includes(query));

// before — P0: index-ключ на переупорядочиваемом списке с состоянием
{rows.map((row, i) => <RowDetail key={i} row={row} />)}
// after — идентичность следует за строкой, а не за слотом
{rows.map((row) => <RowDetail key={row.id} row={row} />)}

Два коммита, два закрытых P0-пункта, ноль новых абстракций. Фича теперь корректна до того, как стала красивой, — и если что-то даст регресс, откат — одна строка.

Раздели раздутый контекст и стабилизируй его значение — но только ту часть, которую оправдывает давление. P1-раздутый контекст перерисовывает каждого потребителя на каждое нажатие клавиши, потому что query, selectedId, theme и data едут в одном значении провайдера. Дели по частоте обновлений, а не ради опрятности: волатильные query/selectedId идут в один контекст, стабильные theme/data — в другой, чтобы потребитель темы больше не перерисовывался, когда ты печатаешь. И оберни каждое значение в useMemo, чтобы новый объектный литерал на каждом рендере не сводил разделение на нет.

// after — два контекста, разделённых по волатильности, каждое значение стабилизировано
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]);              // волатильное — меняется на каждое нажатие
  const data = useMemo(() => ({ rows, theme }), [rows, theme]); // стабильное
  return (
    <DataContext.Provider value={data}>
      <FilterContext.Provider value={filter}>{children}</FilterContext.Provider>
    </DataContext.Provider>
  );
}

Не дроби на пять контекстов потому, что можешь, — дроби, пока высокочастотные обновления не перестанут трогать низкочастотных потребителей. Там кончается давление — там кончается изменение.

Разбери божественный компонент через композицию + вынесенные кастомные хуки — обязанность за обязанностью, а не одним переписыванием. P1-божественный компонент владеет загрузкой, фильтрацией, сортировкой, пагинацией, выбором и рендерингом. Вытягивай по одной обязанности за раз: вынеси жизненный цикл данных в useDashboardData() (кастомный хук), затем нарежь рендеринг на <Toolbar>, <DataTable> и <Detail>. После каждого выноса приложение по-прежнему работает — ты перемещаешь строки в названный дом, а не меняешь поведение.

// выносим обязанность данных в хук (тестируемый, переиспользуемый, одна задача)
function useDashboardData(query: string, sortKey: keyof Row) {
  const rows = use(fetchRows());            // React 19: читаем промис
  return useMemo(
    () => sortRows(rows.filter((r) => r.name.includes(query)), sortKey),
    [rows, query, sortKey],
  );
}

// божественный компонент сжимается до композиции: каждый ребёнок владеет одной обязанностью
function Dashboard() {
  return (
    <DashboardProviders>
      <Toolbar />
      <DataTable />
      <Detail />
    </DashboardProviders>
  );
}

Композиция заодно бесплатно растворяет P2-проброс пропсов: как только RowActions читает selectedId из FilterContext (или сидит прямым ребёнком компонента, который им владеет), четыре транзитных перехода исчезают. Ты не добавил паттерн для проброса — ты позволил структурному исправлению поглотить его.

Колоцируй или подними каждый кусок состояния на уровень, который им владеет, — затем оберни async-границу в Suspense под Error Boundary. С разделёнными обязанностями состояние находит свой уровень: флаг open/closed строки колоцируется внутри <RowDetail> (никого над ним он не волнует), тогда как query/selectedId остаются поднятыми в провайдер, потому что их разделяют два сиблинга. Состояние, которое никто не разделяет, не место в провайдере. Наконец, загрузка данных — единственная async-граница, так что она получает fallback <Suspense> и Error Boundary над собой — колоцированные, потому что граница без UI ошибки — это половина границы.

// состояние на нужном уровне + async-граница сделана явной
function DataTable() {
  return (
    <ErrorBoundary fallback={<TableError />}>
      <Suspense fallback={<TableSkeleton />}>
        <DataRows />          {/* useDashboardData() приостанавливается здесь */}
      </Suspense>
    </ErrorBoundary>
  );
}

function RowDetail({ row }: { row: Row }) {
  const [open, setOpen] = useState(false); // колоцировано — волнует только эту строку
  return <div onClick={() => setOpen((o) => !o)}>{open && <Body row={row} />}</div>;
}

Пять коммитов спустя инвентарь закрыт: каждый P0-баг исчез, контекст разделён, божественный компонент составлен, состояние на своём уровне, async-граница ограничена — и дифф читается как последовательность, а не как взрыв.