Положение строки и её личность различаются
React связывает состояние с положением и типом компонента в дереве интерфейса; ключи помогают различать элементы среди соседей. Если строки имеют стабильные идентификаторы, ключ позволяет связать компонент с конкретной записью даже после изменения порядка внутри списка. Индекс массива описывает текущую позицию, а не саму задачу. После вставки новой записи в начало прежняя вторая строка становится третьей. Если в качестве ключа использовался индекс, связь с локальным состоянием может остаться у позиции, в которой теперь показываются другие данные. Поэтому особенно важно проверять ключи в списках, где возможны вставка, удаление и сортировка.
Ключ должен оставаться стабильным
Удобный ключ обычно берут из устойчивого идентификатора данных. Для локально создаваемой записи идентификатор назначают при создании и сохраняют вместе с ней. Его не нужно заново вычислять случайным образом при каждом отображении. Если ключ каждый раз меняется, React воспринимает элемент как другой и создаёт его заново. Пользовательский ввод и другое локальное состояние при этом могут сбрасываться. Ключ также не является обычным свойством, которое компонент автоматически получает для своей логики. Если самой строке нужен идентификатор задачи, его передают отдельно. Важно понимать обе роли: одна помогает React сопоставить элементы, другая предоставляет данные вашему компоненту.
Определите, где должен жить черновик
Стабильный ключ помогает сохранять связь, но не превращает локальное состояние в постоянное хранилище. Если компонент действительно удалён из дерева, его состояние не обязано восстановиться при последующем появлении. Когда черновик должен переживать скрытие или удаление строки из текущего представления, заранее выбирают подходящего владельца данных. Например, редактируемые заметки можно хранить выше уровня отдельной строки и связывать с идентификатором задачи, если это соответствует устройству приложения. Не стоит одновременно поддерживать несколько независимых копий одной заметки без понятного правила обновления. При проверке сначала определите ожидаемое поведение: должен ли текст сохраниться после сортировки, фильтрации и повторного открытия? Эти сценарии похожи внешне, но могут по-разному влиять на жизнь компонентов.
Попробуйте на практике
Смоделируйте список на бумаге, не создавая проект и не устанавливая пакеты. У каждой задачи есть стабильный идентификатор и локальный черновик заметки.
- Нарисуйте три строки с идентификаторами 101, 202 и 303. Во второй строке запишите условную заметку, относящуюся к задаче 202.
- Переставьте задачи в обратном порядке и покажите, к какой записи должна относиться заметка при стабильных ключах.
- Добавьте новую задачу в начало и сравните два способа ключей: идентификаторы записей и текущие номера позиций.
- Отдельно смоделируйте полное удаление строки из дерева и решите, где нужно хранить заметку, если она должна пережить это действие.
Как проверить результат. Заметка остаётся связанной с задачей 202 при перестановке данных со стабильными ключами. Вы отличаете изменение позиции от удаления компонента и понимаете, что постоянное сохранение текста требует отдельного решения о хранении.
Частые вопросы
Ключ должен быть уникальным во всём приложении?
Нет. Важна уникальность среди соседних элементов соответствующего списка. Одинаковые значения в разных независимых списках сами по себе не являются проблемой.
Почему нельзя просто использовать случайное число?
Если оно заново создаётся при каждом отображении, ключ перестаёт быть стабильным. Случайно сформированный идентификатор допустим как сохранённое свойство новой записи, но не как постоянно меняющаяся замена личности элемента.
Любая потеря текста связана с ключами?
Нет. Возможны ошибки обновления состояния, смена типа компонента или его удаление. Ключи являются одной из проверок, которую нужно сопоставлять с реальным сценарием интерфейса.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.