Неправильный контекст и индекс как key

Антипаттерн A: контекст, чьё значение часто меняется, перерисовывает каждого потребителя — как бы глубоко тот ни был. Provider контекста перерисовывает всех потребителей всякий раз, когда идентичность его value меняется. Положи частое состояние — управляемый инпут, позицию мыши, таймер — в широкий контекст, и каждый потребитель в поддереве перерисовывается на каждое нажатие клавиши или кадр. «Удобство» не прокидывать пропс оборачивается штормом рендеров по всему дереву.

// Антипаттерн: черновик формы (меняется на каждое нажатие) общий на всё приложение
const AppContext = createContext<{ draft: string; setDraft: (s: string) => void } | null>(null);

function App() {
  const [draft, setDraft] = useState("");
  // каждое нажатие → новый объект value → ВСЕ потребители перерисовываются
  return (
    <AppContext.Provider value={{ draft, setDraft }}>
      <Header />   {/* перерисовывается на каждое нажатие */}
      <Sidebar />  {/* перерисовывается на каждое нажатие */}
      <Editor />   {/* единственное, кому draft реально нужен */}
    </AppContext.Provider>
  );
}

Это проходит демо, потому что три дешёвых ребёнка, перерисовываясь, незаметны. В проде эти дети — дорогие деревья, и печать тормозит.

Фикс — это область, а не отказ: держи частое или чисто локальное состояние вне широкого контекста — колокируй его или разбей контекст по частоте изменений. Если черновик нужен только Editor, это состояние принадлежит Editor (или его ближайшему общему родителю), а не корню приложения. Когда состояние действительно общее, но смешивает стабильные и волатильные данные, разбей его: редко меняющийся контекст (тема, пользователь) остаётся широким; волатильный срез получает собственный узкий provider или вовсе выезжает наружу. Помни также, что свежий объект value={{ ... }} на каждом рендере сам по себе триггерит перерисовку — мемоизируй его, когда контекст законно остаётся широким.

// Фикс: черновик живёт там, где используется; контекст несёт лишь стабильные общие данные
const ThemeContext = createContext<Theme>("light"); // меняется редко → безопасно быть широким

function App() {
  const theme = useTheme();
  return (
    <ThemeContext.Provider value={theme}>
      <Header />
      <Sidebar />
      <Editor /> {/* владеет своим draft useState — нет churn по всему дереву */}
    </ThemeContext.Provider>
  );
}

Ограничь область каждого куска состояния ровно теми, кому он нужен. Контекст — для общего состояния и работает лучше всего, когда это общее состояние меняется нечасто.

Антипаттерн B: key={index} привязывает идентичность компонента к его позиции, так что любая пересортировка/вставка/удаление заставляет React переиспользовать не тот инстанс. Key говорят React, какой элемент какой между рендерами. С индексными key «элемент на позиции 0» всегда key 0 — так что если ты вставляешь в начало, в середину или сортируешь, React думает, что новый элемент на позиции 0 — это тот же элемент, что и раньше, и держит внутреннее состояние старого компонента (текст инпута, фокус, выделение, скролл, чекбокс) привязанным к неверным данным.

// Антипаттерн: индексные key на списке, который пользователь может пересортировать / дополнять
{todos.map((todo, i) => (
  <li key={i}>
    {todo.label}
    <input defaultValue={todo.note} /> {/* неуправляемое состояние живёт в DOM-узле */}
  </li>
))}
// Вставь todo в начало → каждый инпут note теперь показывает текст ПРЕДЫДУЩЕЙ строки.

Статичные, никогда не пересортируемые списки переживают индексные key — именно поэтому это проскакивает ревью: баг спит, пока список не мутирует.

Фикс — это стабильная идентичность: ключуй по значению, которое путешествует вместе с элементом — серверный id или сгенерированный id, созданный при рождении элемента, никогда не индекс массива и никогда Math.random(). Стабильный key означает, что React держит каждый компонент приклеенным к его собственным данным сквозь любую пересортировку, так что текст инпута, фокус и выделение следуют за нужной строкой. Обе перекоррекции проваливаются: key={Math.random()} производит новый key на каждом рендере, так что React перемонтирует каждую строку на каждом рендере (состояние потеряно, фокус потерян, худший случай). А key={JSON.stringify(item)} перекеширует всякий раз, когда меняется любое поле, перемонтируя при правке.

// Фикс: стабильный id, принадлежащий элементу
{todos.map((todo) => (
  <li key={todo.id}>{todo.label}<input defaultValue={todo.note} /></li>
))}
// Если у источника нет id, отчекань его во время создания, а не во время рендера:
const addTodo = (label: string) =>
  setTodos((t) => [...t, { id: crypto.randomUUID(), label, note: "" }]);

Индексные key приемлемы только когда список статичен, никогда не пересортируется/фильтруется, а у элементов нет идентичности и нет внутреннего состояния — замороженное меню, а не редактируемый пользователем список.