Reconciliation и keys: где на самом деле живёт ваше состояние

Diff — это эвристика, а не поиск по дереву

Настоящий минимальный diff двух деревьев стоит O(n³) — для тысячи элементов это порядка миллиарда сравнений, мертворождённая идея для UI, который ре-рендерится на каждое нажатие. React отказывается играть в эту игру и ставит на две эвристики, почти всегда верные в реальных интерфейсах. Первая: элементы разных типов порождают разные деревья — если на позиции был div, а стал section, или был UserProfile, а стал LoginForm, React внутрь не заглядывает. Он размонтирует всё старое поддерево (уничтожая всё состояние в нём, выполняя cleanup-эффекты, удаляя DOM) и монтирует новое с нуля. Вторая: разработчик может пометить стабильную идентичность между рендерами через key. С этими двумя допущениями reconciliation выполняется за O(n).

Само сравнение идёт позиция за позицией. Тот же тип на той же позиции: React сохраняет существующий fiber (внутренний узел, где живут состояние хуков, DOM-узел и флаги изменений), обновляет его пропсы и рекурсивно спускается в детей — экземпляр компонента выживает, его хуки выживают. Другой тип: полный снос этого поддерева. Поэтому же сравниваются именно описания-элементы, а не «экземпляры» компонентов — элементы пересоздаются свежими объектами на каждом рендере и не несут никакого состояния. Это одноразовые описания; персистентная сущность, с которой их сопоставляют, — fiber.

Состояние живёт на fiber, а key — правило сопоставления

Если ты когда-нибудь удивлялся, почему инпут сохраняет набранный текст между ре-рендерами — вот ответ: всё, что выдаёт useState, хранится на fiber — не в вашем JSX и не в замыкании функции: функция отработала и вернулась, её локальные переменные исчезли. Так что у вопроса «где текст моего инпута?» есть точный ответ: на том fiber, который React сопоставил вашему элементу при последнем reconciliation. Для одиночного ребёнка сопоставление идёт по позиции и типу. Для массива соседей позиция бессмысленна — списки пересортировывают, фильтруют, дополняют сверху — поэтому соседей React сопоставляет по key: старый fiber с key «a» соединяется с новым элементом с key «a», куда бы тот ни переехал. Сопоставленный fiber сохраняет состояние и свой DOM-узел, а перемещение стоит одну перестановку DOM-узла вместо сноса.

Теперь механизм поломки из пролога, точно. С key={index} ключ и есть позиция — вы переформулировали дефолт и отключили весь механизм сопоставления. Пересортируйте данные, и React видит: на позиции 0 всё ещё key 0, тот же тип → тот же fiber → то же состояние. Fiber, державший черновик для руководителя, теперь получает пропсы переписки с кандидатом. Всё, что живёт на fiber или его DOM-узле, прилипает к позиции вместо того, чтобы следовать за данными: текст неконтролируемого инпута, чекбоксы, фокус, позиция скролла, useState внутри строки, даже мемоизированные значения. Удаление первого элемента — тот же баг в другом костюме: каждый fiber сдвигается на новый элемент данных, а размонтируется последний fiber — отсюда «я удалил первую строку, но пропали заметки второй, а первая сохранила заметки удалённого тикета».

const [convos, setConvos] = useState(initialConvos);
// convos пересортируется при каждом новом сообщении в треде

// Баг: key повторяет позицию. После пересортировки fiber (и состояние
// неконтролируемого инпута на нём) на позиции 0 сопоставляется с тем,
// какой разговор теперь оказался на позиции 0.
{convos.map((c, index) => (
  <ConversationRow key={index} convo={c} />
))}

// Исправление: key = стабильная идентичность из данных. Fiber следует за
// разговором куда угодно; React переставляет DOM-узел.
{convos.map((c) => (
  <ConversationRow key={c.id} convo={c} />
))}

Два следствия, о которых сеньоров спрашивают на ревью. key={Math.random()} — противоположный баг, и строго хуже: ни один key никогда не совпадает, поэтому каждый рендер размонтирует и заново монтирует все строки — состояние стирается на каждом рендере, эффекты переигрываются, DOM перестраивается целиком; таблица на 200 строк превращается из горстки точечных патчей в 200 циклов снос-и-создание на каждое нажатие. И второе: key обязан быть уникален только среди соседей, не глобально — item.id годится, даже если другой список в приложении использует те же id.

Идентичность элемента vs идентичность компонента: сбросы, которых вы не заказывали

Обратная сторона правила «тот же тип сохраняет состояние»: тот же тип компонента на той же позиции сохраняет состояние даже между совершенно разными ветками JSX. Отрендерите <Counter person="Taylor" /> в true-ветке тернарника и <Counter person="Sarah" /> в false-ветке: переключение не сбрасывает счётчик. React видит позицию 1, тип Counter — оба раза: тот же fiber, пропсы обновлены, состояние сохранено. Если логически это разные счётчики, это баг, и лечится он разными key у веток — key="taylor" и key="sarah" — превращая key в осознанный рычаг сброса. Тем же рычагом сбрасывают форму при смене сущности: <ProfileForm key={userId} /> перемонтирует всю форму при переключении пользователя, вместо того чтобы правки одного пользователя протекли в профиль другого.

И обратный сценарий отказа: определение компонента внутри другого компонента. Внутренняя функция пересоздаётся на каждом рендере родителя, поэтому её идентичность каждый раз другая; для функциональных типов React сравнивает по ссылке, видит «другой тип» на той же позиции — и размонтирует поддерево: каждый рендер родителя стирает состояние ребёнка, сбрасывает фокус, переигрывает эффекты монтажа. Выглядит как «мой инпут теряет фокус на каждом нажатии» и входит в число самых частых не-багов в трекере React. Поднимите определение на уровень модуля; нужны данные родителя — передайте пропсы.