В каких случаях нельзя в key в React ставить индекс элемента массива

Почему индекс массива — плохой ключ в React

Использование индекса элемента массива как значения для свойства key в React — одна из самых распространённых ошибок среди начинающих разработчиков. На первый взгляд, это выглядит логичным и удобным: индекс уникален в пределах массива и легко доступен. Однако, в большинстве случаев это нарушает фундаментальное предназначение key и приводит к серьёзным проблемам.

Основная цель key

Атрибут key помогает React идентифицировать элемент в списке между рендерами. Его главные задачи:

• Стабильная идентификация компонента или элемента DOM.
• Повторное использование существующих DOM узлов при изменении списка (для эффективности).
• Сохранение состояния компонента (например, значения в input, состояние чекбокса, фокус) при ре-рендере списка.

Когда вы используете индекс как key, эти цели не достигаются, потому что индекс не является стабильным и уникальным идентификатором элемента данных. Он зависит от позиции в массиве, которая может меняться, а не от сущности самого элемента.

Конкретные ситуации, когда индекс как key приводит к проблемам

1. Изменение порядка элементов в списке (Сортировка, Фильтрация, Добавление/Удаление в начале)

Это самый критичный случай. Если список изменяется не только в конце, его индексы пересчитываются. React, сравнивая key по индексам, может некорректно сопоставить старые и новые элементы.

// Начальный список
const initialItems = ['Альфа', 'Бета', 'Гамма'];
// Рендер с ключами-индексами: key=0, key=1, key=2

// Удаляем первый элемент 'Альфа'
const filteredItems = ['Бета', 'Гамма'];
// Новые индексы: key=0, key=1

React увидит, что элемент с key=0 ('Альфа') исчез, а появились элементы с key=0 ('Бета') и key=1 ('Гамма'). Он может сохранить DOM-узлы старых элементов и просто обновить их содержимое текстом новых данных. Это приводит к:

• Потере внутреннего состояния компонентов: если 'Бета' была чекбоксом и находилась в состоянии checked, после удаления 'Альфы' и её перемещения на индекс 0, чекбокс может сохранить неверное состояние.
• Некорректным атрибутам DOM: например, фокус на input мог быть на элементе с индексом 2 ('Гамма'), но после удаления первого элемента фокус может "переехать" на новый элемент с индексом 1, что нарушает UX.
• Снижению производительности: React не сможет оптимально перемещать существующие DOM узлы, что приводит к более частым операциям создания/удаления.

2. Динамические списки с изменяемой структурой данных

Если элементы списка сами являются сложными компонентами, которые могут менять своё состояние или внутреннюю структуру в зависимости от данных, использование индекса как key сделает это состояние нестабильным при любых изменениях массива, даже если сами данные элемента не изменились.

3. Списки, где элементы могут иметь одинаковое содержимое

Если в массиве есть потенциально дублирующиеся данные (например, несколько товаров с одинаковым названием), индекс становится единственным "различителем". При операциях с массивом React может спутать элементы, считая, что один дубликат превратился в другой.

// Плохо: key зависит только от позиции
{items.map((item, index) => <Product title={item.title} key={index} />)}

// Хорошо: key использует уникальный идентификатор данных
{items.map((item) => <Product title={item.title} key={item.id} />)}

4. Когда производительность имеет ключевое значение

React использует key для построения своего внутреннего "diff" алгоритма. Стабильные ключи позволяют ему быстро находить соответствия между элементами предыдущего и следующего рендера. Нестабильные ключи (как индексы при изменении списка) заставляют React выполнять более тяжелые вычисления и чаще манипулировать DOM.

Когда индекс МОЖНО использовать (редкие исключения)

Есть несколько сценариев, где использование индекса допустимо, но они очень ограничены:

• Статический, никогда не изменяемый список. Если массив фиксирован на всю жизнь компонента и его порядок/состав никогда не меняется (например, список месяцев года).
• Список без внутреннего состояния. Если элементы списка являются простыми, "статичными" компонентами или элементами DOM, которые не имеют своего состояния (не управляются через useState, не являются контролируемыми формами, не содержат фокус или другие DOM атрибуты).
• Отсутствие уникального идентификатора в данных. В крайнем случае, если в данных действительно нет никакого уникального поля (id, uuid, slug). Но даже тогда следует рассмотреть генерацию уникального ключа на основе содержимого (хэш) или использовать специальные библиотеки.

Практические рекомендации

Идеальный key — это уникальный и неизменный идентификатор, принадлежащий самим данным, например:

• id из базы данных
• uuid, сгенерированный на клиенте или сервере
• Уникальная комбинация полей (например, name + timestamp), если других вариантов нет.

// ✅ Правильный подход: использование стабильного идентификатора данных
const todoList = todos.map(todo => (
  <TodoItem
    key={todo.id} // Используется уникальный ID, присущий объекту todo
    task={todo.task}
    completed={todo.completed}
  />
));

// ❌ Опасный подход: использование индекса массива
const todoList = todos.map((todo, index) => (
  <TodoItem
    key={index} // Индекс меняется при любой операции с массивом!
    task={todo.task}
    completed={todo.completed}
  />
));

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