React: ключи для сброса состояния компонента

Вид спереди MacBook Pro

Коротко: при условном рендеринге одного и того же компонента с разными props React может повторно использовать экземпляр компонента и сохранить его состояние. Решения: изменить структуру DOM или задать уникальные key для каждого варианта, чтобы заставить React смонтировать новый компонент и сбросить state.

React прост по синтаксису, но у него есть тонкости. Одна из частых неприятностей — неожиданные состояния при условном рендеринге одного и того же компонента с разными props. Ниже — подробное объяснение причины, пошаговые примеры, альтернативные подходы, контрольные чек-листы и примеры для тестирования.

Суть проблемы: компоненты не всегда независимы

React использует процесс, называемый реконсиляцией, чтобы сопоставить виртуальное представление DOM между рендерами. Если на той же позиции дерева элементов появляется «тот же» элемент (по типу и позиции), React пытается повторно использовать существующий экземпляр вместо создания нового. Это экономит рендер, но влечёт за собой ситуацию, когда внутренний state компонента остаётся прежним, даже если изменилась логика или props.

Классический пример — компонент Counter, который хранит локальный state (count). В родительском компоненте вы условно рендерите Counter с name=”Kingsley” или name=”Sally”. Поскольку структура элементов одна и та же, React считает, что это один и тот же компонент, и повторно использует его внутреннее состояние. В результате при переключении имён счётчик не сбрасывается.

Пример компонента Counter

import { useState, useEffect } from "react"  
  
export function Counter({name}) {  
  const [count, setCount] = useState(0)  
  
  return(  
      
      {name}  
        
      
  
        
      
  )  
}

И родительский компонент, демонстрирующий проблему:

import { useState } from "react"  
import { Counter } from "./Counter"  
  
export default function App() {  
  const [isKingsley, setIsKingsley] = useState(true)  
  
  return(  
      
      { isKingsley ?  :   }  
      
  
        
      
  )  
}

Поведение: увеличьте счётчик для Kingsley до 5, нажмите Swap — на экране появится Sally, но значение останется 5, т.к. состояние было переиспользовано.

Почему это происходит: модель идентичности элементов

Короткая модель: при реконсиляции React использует тип элемента и его позицию в дереве, чтобы решить, можно ли повторно использовать существующий экземпляр. React не сравнивает все props для принятия решения об идентичности — это намеренно: сравнивать всё было бы дорого и часто не нужно. Вместо этого используется понятие ключа (key) для явного указания идентичности.

Важно: props влияют на рендер, но сами по себе не указывают на то, что экземпляр должен быть заменён. Если вам нужно, чтобы компонент сбрасывал state при изменении «ключевого» свойства, используйте key.

Два способа решить проблему

Изменить структуру DOM так, чтобы элементы занимали разные позиции/узлы; тогда React смонтирует новый компонент.
Назначить уникальные атрибуты key для разных вариантов компонента — это самый распространённый и явный способ.

Пример 1 — изменить структуру DOM (обновляет дерево):

import { useState } from "react"  
import { Counter } from "./Counter"  
  
export default function App() {  
  const [isKingsley, setIsKingsley] = useState(true)  
  
  return (  
      
      { isKingsley ?   
        (  
             
        )  
        :    
        (  
             
        )  
      }  
      
  
        
      
  )  
}

Плюс: работает без модификации компонента Counter. Минус: требуется менять разметку, что не всегда уместно.

Пример 2 — использовать key (предпочтительно):

import { useState } from "react"  
import { Counter } from "./Counter"  
  
export default function App() {  
  const [isKingsley, setIsKingsley] = useState(true)  
  
  return(  
      
      { isKingsley ?   
         :    
           
      }  
      
  
        
      
  )  
}

Здесь React распознаёт разные key и создаёт новый экземпляр Counter при переключении, т.е. state сбрасывается.

Часто встречающаяся ошибка: использование индекса массива в key

При рендеринге списков многие используют index как key, например key={index}. Это на первый взгляд работает, но приводит к проблемам при изменении порядка элементов, вставках или удалениях: React будет путать элементы и переносить state не туда, где ожидалось. Правило: ключи должны быть стабильными и уникальными для элемента в пределах списка. Идеальные ключи — постоянные уникальные идентификаторы (id).

export default function App() {  
  const names = ["Kingsley", "John", "Ahmed"]  
  
  return(  
      
      { names.map((name, index) => {  
        return   
      })}  
      
  )  
}

Лучше:

{ users.map(user => ) }

Продвинутые сценарии: связывание элементов через ключи

Ключи можно использовать не только для списков, но и чтобы связать любое DOM-или React-дерево с логикой. В примере ниже input получает ключ, зависящий от состояния, что заставляет React полностью пересоздавать элемент input при переключении:

import { useState } from "react"  
  
export default function App() {  
  const [isKingsley, setIsKingsley] = useState(true)  
  
  return(  
      
      { isKingsley ? Kingsley's Score
 : Sally's score }  
        
      
  
        
      
  )  
}

Это полезно, если вы хотите сбрасывать внутреннее состояние контролируемого/неконтролируемого элемента ввода при смене контекста.

Когда ключи не решают задачу

Когда проблема связана не с повторным использованием экземпляра, а с побочными эффектами (useEffect) — тогда нужно проверить зависимости эффекта.
Когда state намеренно должен быть общий между вариантами — в этом случае поднимите состояние вверх (lifting state up) и управляйте им из родителя.
Когда ключи нестабильны (генерируются заново при каждом рендере) — это снова приведёт к ненужным монтированиям.

Примеры ошибок:

Использование Math.random() для key: каждый рендер создаст новый ключ и React будет постоянно размонтировать/монтировать компонент.
Использование индекса в списках, где элементы могут перемешиваться.

Альтернативные подходы и паттерны

Поднять состояние в родительский компонент (lifting state up), чтобы разные варианты компонента читали общее состояние и корректно реагировали на смену props.
Делать компонент контролируемым: полностью управлять его значением через props и передавать set-функции из родителя.
Использовать useEffect для наблюдения изменений props и вручную сбрасывать state, если это безопасно.
Создать вспомогательный контейнер, который при переключении возвращает null, а затем новый компонент — это похожее на key поведение, но может быть менее очевидно.

Руководство: как выбрать между структурой DOM и key

Если можно изменить структуру без ущерба для семантики и стилей — это быстрый способ.
Если изменение структуры недопустимо (из-за CSS, ARIA, семантики) — используйте key.
Если нужно сохранять часть состояния между вариантами, но сбрасывать другую — поднимите состояние и контролируйте его по-частям.

Важно: чаще всего key — самый явный и удобный способ управления жизненным циклом экземпляра.

Контрольный чек-лист перед релизом

Для каждого списка заданы устойчивые ключи (id, не index).
Ключи не генерируются случайно при каждом рендере.
Если компонент должен сбрасывать state при смене контекста — используется key или перенесён state в родителя.
useEffect имеет правильный массив зависимостей и не вызывает побочных эффектов при реконсиляции.
Проверены изменения DOM-структуры на предмет влияния на стили и доступность.

Критерии приёмки

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

Мини-методология для команд

При проектировании компонентов заранее продумать, должен ли state быть локальным или общим.
Для списков договориться об источнике truth для ключей (например, id в БД или UUID, созданный при добавлении).
В код-ревью проверять ключи на стабильность и уникальность.
Добавить unit/integration тест, проверяющий, что переключение контекста сбрасывает/сохраняет state как ожидалось.

Примеры тест-кейсов

Тест: увеличиваем счётчик, переключаем на другой вариант, ожидаем 0 — проверяет поведение при задании key.
Тест: рендерим список, меняем порядок элементов, проверяем, что state элементов переместился с корректными объектами (т.е. ключи устойчивы).
Тест: проверка, что использование index в качестве key приводит к неверному поведению при вставке элемента в начало списка.

1-строчный глоссарий

Reconciliation — процесс сопоставления виртуального дерева React между рендерами.
Key — уникальный идентификатор элемента для помощи React в реконсиляции.
Lifting state up — перенос состояния в родителя для совместного использования.

Заключение

Ключи — простой и мощный инструмент контроля жизненного цикла компонентов в React. Они дают возможность явно указать React, когда компонент нужно пересоздать, что помогает избежать тонких багов со старыми значениями state. В большинстве случаев предпочитайте стабильные уникальные ключи над индексами, думайте о том, где должно храниться состояние, и добавляйте тесты, подтверждающие ожидаемое поведение.

Важно

Если вы используете React Native, те же принципы работают — ключи и реконсиляция работают одинаково в обоих окружениях.

FAQ

Что такое React Native?

React Native расширяет React для разработки кросс-платформенных мобильных приложений: вы пишете компонентную логику на JavaScript/JSX и получаете нативные UI-элементы на iOS и Android.

Всегда ли компоненты должны быть 100% изолированы?

Нет. Изоляция удобна, но иногда требуется совместное состояние. В таких случаях поднимите state в родителя или используйте глобальное хранилище. Избыточная «изоляция» может привести к prop drilling и усложнить код.

Как сделать компонент гибким с помощью props?

Делайте компонент контролируемым или предоставляйте вспомогательные props (например, onChange), чтобы родитель мог управлять поведением. Props — это основной способ настройки компонента и его поведения.