> Что будет, если передать в React diff div без key (React)

Короткий ответ

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

Подробное объяснение

Когда React выполняет diff (reconciliation) для списка дочерних элементов, он использует key для идентификации каждого элемента. Если key не указан, React по умолчанию использует индекс элемента в массиве. Это создаёт несколько проблем:

1. Потеря состояния: при добавлении элемента в начало списка все последующие элементы получат новые индексы, React пересоздаст их DOM-узлы и сбросит локальное состояние (например, input, scroll position).

2. Лишние перерисовки: при удалении элемента из середины React не сможет определить, какой элемент был удалён, и перерисует все последующие.

3. Проблемы с анимациями: неправильное сопоставление элементов ломает CSS-анимации и transition.

4. Ошибки в controlled компонентах: если элементы содержат формы или input, их значения могут "перемешиваться".

Механизм React сравнивает элементы по key и типу компонента. Без стабильного key (например, уникального id) React вынужден использовать index, что делает diff неэффективным. В React 18+ алгоритм стал умнее, но фундаментальная проблема остаётся.

На практике

• Статические списки (без изменений после монтирования) - index как key допустим, но не рекомендуется.
• Динамические списки (сортировка, фильтрация, добавление/удаление) - обязательно используйте уникальный и стабильный key (id из БД, uuid).
• Не используйте random() или Date.now() - это ломает идентификацию при каждом рендере.
• Key должен быть уникальным среди siblings, не обязательно глобально.
• Для массивов объектов - используйте item.id, если id нет - генерируйте при создании.
• В React Native та же проблема, key критичен для FlatList.
• React StrictMode в dev-режиме дважды вызывает рендер, что может выявить проблемы с key.

Пример кода

JSX
// Плохо: index как key
function TodoList({ items }) {
  return (
    <ul>
      {items.map((item, index) => (
        <li key={index}>{item.text}</li>
      ))}
    </ul>
  );
}

// Хорошо: уникальный id
function TodoList({ items }) {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.text}</li>
      ))}
    </ul>
  );
}

// Демонстрация проблемы
function App() {
  const [items, setItems] = useState(['a', 'b', 'c']);
  
  const addFirst = () => setItems(['x', ...items]);
  
  return (
    <div>
      <button onClick={addFirst}>Add 'x' first</button>
      {items.map((item, index) => (
        <div key={index}>
          <input defaultValue={item} />
          <span>{item}</span>
        </div>
      ))}
    </div>
  );
}
// После добавления 'x' в начало - input'ы потеряют значения

Как отвечать на собеседовании

Начните с чёткого ответа: React использует index как key по умолчанию. Объясните, почему это проблема - потеря состояния и производительность. Приведите конкретный пример с input. Упомяните, что для статических списков это может работать, но это антипаттерн. Подчеркните важность стабильного key (id). Если спросят про React 18 - скажите, что алгоритм улучшился, но проблема остаётся. Избегайте излишних деталей про Fiber или виртуальный DOM, если не спрашивают.

Что проверяет интервьюер

• Понимание механизма reconciliation в React.
• Знание разницы между key и index.
• Умение предсказывать поведение UI при изменении данных.
• Практический опыт с багами из-за key.
• Понимание trade-off между производительностью и корректностью.

Типичные ошибки

• Утверждение, что без key React не работает - работает, но плохо.
• Использование key={Math.random()} - ломает идентификацию.
• Использование key={index} для динамических списков с сортировкой.
• Игнорирование проблемы для списков с формами или анимациями.
• Путаница между key и ref.
• Думать, что key нужен только для производительности - на самом деле для корректности.