Зачем key важен
- React использует ключи при «reconciliation» (сопоставлении старого и нового виртуального DOM) для определения, какие элементы добавлены, удалены или перемещены. Ключи задают идентичность элемента между рендерами — при стабильном ключе React сохраняет (и реиспользует) DOM-узел и внутреннее состояние компонента, при смене ключа — уничтожает старый и создает новый.
Чем опасно использование индексов (key={index})
- Если порядок списка меняется, элементы вставляются или удаляются, индекс перестает быть стабильным: один и тот же индекс в новом массиве может соответствовать другому логическому элементу. Это вызывает баги:
- Поля ввода «перемещают» введенный текст в другой элемент.
- Локальное состояние дочерних компонентов привязывается к не тому элементу.
- Неправильные анимации или неожиданные эффекты жизненного цикла (componentDidMount/Unmount).
- Типичный сценарий (упрощённо): был список [A,B,C] с ключами по индексам $0,1,2$. Вставили D в начало → новый порядок [D,A,B,C] с индексами $0,1,2,3$. React сопоставит старые DOM-узлы по индексам, и содержимое A окажется в DOM узле, который теперь должен представлять D.
Конкретный пример багa (inputs с index key)
Проблемный код:
```
items.map((item, i) => (
))
```
При вставке нового элемента в начало — все input-ы сдвинутся: текст останется в DOM-узле, но будет относиться к другому item.
Исправление: использовать стабильный уникальный идентификатор
Правильно:
```
items.map(item => (
))
```
Требования к ключу: уникален среди соседей и стабилен для одного логического элемента между рендерами.
Как получить стабильные ключи, если их нет в данных
- Лучше: добавлять уникальный id на этапе получения/создания данных (сервер, при добавлении элемента).
- Если невозможно хранить id в источнике данных: при первом рендере сгенерировать и прикрепить id один раз (например, добавлять поле id в объект при загрузке; или использовать useRef / map, чтобы присвоить id только один раз). Важно: не генерировать случайный id на каждом рендере (например, crypto.randomUUID() прямо в render) — это разрушит стабильность ключей.
- Библиотеки: nanoid, uuid и т.п. — но генерируйте при создании объекта, а не при каждом рендере.
Когда индекс допустим
- Только если список статичен: порядок и содержимое никогда не меняются (т.е. рендерится один раз) или вы точно знаете, что элементы никогда не вставляются/удаляются/переставляются. Во всех остальных случаях — не использовать.
Краткая проверка/чеклист
- Есть у данных уникальный id? → использовать его.
- Если id нет — добавить/сгенерировать один раз при создании данных, не в render.
- Не использовать index при потенциальной перестановке/вставке/удалении.
- Убедиться, что ключи уникальны среди прямых детей одного списка.
Вывод: key нужен для корректного сопоставления элементов между рендерами. Индексы как ключи ломают это сопоставление при изменении порядка/длины списка — приводят к потерям фокуса, «перескакиванию» значений и неправильным эффектам; решается стабильными уникальными id, созданными и сохранёнными вместе с элементами.