Компонент описывает часть интерфейса
Компонент удобно рассматривать как самостоятельную часть отображения с понятной ответственностью. В списке задач можно выделить строку, список целиком и форму добавления. Границы выбирают по смыслу, а не по желанию разбить каждую строчку на отдельный файл. Входные параметры передают данные от родительского компонента к дочернему. Такой поток помогает понять, откуда берётся текст и кто определяет его значение. Один и тот же компонент строки может отображать разные задачи, если получает соответствующие данные.
Состояние хранит изменяющуюся информацию
Обычная локальная переменная и состояние компонента выполняют разные роли. Состояние позволяет сохранять необходимую информацию между отображениями и запускать обновление интерфейса через предусмотренный механизм. Для списка задач это могут быть сами записи и выбранный фильтр. При этом не каждую вычисляемую величину нужно хранить отдельно. Если число видимых задач можно получить из списка и фильтра, дополнительная копия создаёт риск расхождения. Полезно спрашивать: является ли значение самостоятельным источником данных или его можно вывести из уже имеющихся сведений?
Событие выражает намерение пользователя
Нажатие кнопки, изменение поля и отправка формы вызывают обработчики событий. Хороший обработчик связан с конкретным действием: добавить задачу, переключить отметку, изменить фильтр. Он не должен зависеть от случайного внешнего вида элемента. Дальше формируется новое состояние, по которому строится следующее отображение. Для объектов и массивов важно использовать подход к обновлению, который не меняет прежнее состояние напрямую. Это делает поток данных понятнее и помогает избежать ошибок, когда разные части программы неожиданно видят изменённый общий объект.
Идентичность элемента отличается от позиции
У задачи полезно иметь устойчивый идентификатор, который сохраняется при сортировке и фильтрации. Порядковый номер в текущем списке описывает место, а не саму запись. Когда порядок меняется, смешение этих понятий может привести к неверному сопоставлению элементов. При отображении коллекций React использует ключи для согласования соответствующих частей интерфейса. Поэтому ключ должен отражать устойчивую идентичность в подходящем контексте. Проверять поведение полезно не только на добавлении, но и на удалении, перестановке и изменении фильтра.
Попробуйте на практике
Спроектируйте состояние небольшого списка задач на бумаге без настройки проекта.
- Запишите три задачи с разными устойчивыми идентификаторами, текстом и признаком выполнения.
- Добавьте фильтр «все» или «выполненные» и определите, какие записи видны в каждом случае.
- Опишите событие переключения одной задачи и новое состояние, не изменяя исходную запись на листе.
- Переставьте задачи и проверьте, что идентификатор относится к той же задаче, а количество видимых записей вычисляется из данных.
Как проверить результат. Модель корректна, если источник каждого значения понятен, событие приводит к определённому обновлению, а идентичность не зависит от позиции в списке.
Частые вопросы
Нужно ли хранить в состоянии всё, что видно на экране?
Нет. Часть значений можно вычислять из других данных. Лишние копии усложняют согласование и требуют отдельного обновления.
React заменяет знание JavaScript?
Нет. Функции, объекты, массивы и обработка данных остаются основой работы. Библиотека задаёт модель построения интерфейса, используя возможности языка.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.