> При каком условии дочернее дерево в React полностью перестраивается с нуля (React)

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

Дочернее дерево в React полностью перестраивается с нуля, когда меняется key элемента или когда тип элемента (tag name или компонент) отличается от предыдущего. При смене key React не пытается повторно использовать DOM-ноды, а удаляет старые и создаёт новые. То же самое происходит при переходе от <div> к <span> или от одного компонента к другому.

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

React использует алгоритм reconciliation (сверки) для сравнения виртуальных DOM-деревьев. Ключевое правило: если два элемента имеют разный тип, React уничтожает всё поддерево и строит его заново. Например, при смене <div> на <section> все дочерние компоненты теряют состояние, эффекты сбрасываются, DOM-ноды пересоздаются.

Механизм с key работает иначе: при одинаковом типе элемента, но разных key, React также полностью перестраивает поддерево. Это используется для принудительного сброса состояния - например, при изменении идентификатора списка или формы. Если key не указан, React использует индекс элемента в массиве, что может привести к некорректному поведению при переупорядочивании.

Важно: если тип элемента совпадает и key одинаков (или не указан), React рекурсивно обновляет только изменившиеся атрибуты и дочерние элементы, не пересоздавая DOM-ноды. Это оптимизация, позволяющая сохранять состояние и фокус.

На практике

При разработке форм или списков с динамическими данными смена key - это осознанный инструмент для сброса состояния. Например, при переключении между разными профилями пользователей можно использовать key={userId}, чтобы каждый раз создавать чистый экземпляр компонента с новым состоянием. Однако злоупотреблять этим не стоит - излишнее пересоздание деревьев ухудшает производительность.

В реальных проектах часто встречается ошибка: использование индекса массива как key при изменяемом списке. Это приводит к тому, что React переиспользует DOM-ноды для разных элементов, вызывая баги с состоянием (например, фокус в input или анимации). Правильное решение - использовать уникальный идентификатор из данных.

Пример кода

JSX
// Неправильно: key=index приводит к некорректному переиспользованию
{items.map((item, index) => <Item key={index} data={item} />)}

// Правильно: уникальный id гарантирует корректное обновление
{items.map(item => <Item key={item.id} data={item} />)}

// Принудительный сброс состояния через key
{currentUser && <Profile key={currentUser.id} user={currentUser} />}

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

Начни с чёткого условия: разный тип элемента или смена key. Затем поясни, что это часть алгоритма reconciliation - React сравнивает тип и key на первом уровне. Упомяни, что при одинаковом типе и key происходит обновление, а не перестроение. Приведи практический пример: смена key для сброса состояния формы. Избегай излишних деталей про fiber tree, если не спрашивают. Закончи кратким резюме: "Таким образом, полное перестроение происходит только при изменении типа или key".

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

Интервьюер оценивает понимание фундаментального механизма React - reconciliation. Он хочет убедиться, что кандидат знает, когда React уничтожает DOM-ноды, а когда обновляет их. Важно показать осознание trade-off: перестроение гарантирует чистоту состояния, но дорого по производительности. Также проверяется знание правильного использования key - не только для списков, но и для сброса состояния. Ошибка в ответе (например, "key всегда вызывает перестроение") сразу показывает пробел в знаниях.

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

• Утверждение, что перестроение происходит при любом изменении props или state - это неверно, React обновляет существующие ноды.
• Игнорирование роли типа элемента - многие думают только про key.
• Путаница между перестроением поддерева и ререндером компонента: ререндер - это вызов функции компонента, а перестроение - удаление и создание DOM-нод.
• Использование индекса как key без понимания последствий - частая ошибка в коде.
• Мысль, что key нужен только для массивов - на самом деле он работает для любого элемента.