Изменение состояния фронтенд-приложения не всегда означает изменение данных, с которыми работает приложение. У данных может быть состояние, которое влияет только на внешний вид. На сервере, в базе данных, такое состояние отсутствует.
Представьте себе обычный аккордеон. Это способ отображения данных, с помощью которого можно скрыть или раскрыть какой-то из элементов списка. Для работы подобного аккордеона нужно состояние, описывающее отображение каждого элемента: свернут/раскрыт. Такое состояние называется UI-состоянием, то есть состоянием интерфейса пользователя. Где должно храниться это состояние?
Например, его можно поместить внутрь самих данных:
// Список компаний. За отображение в аккордеоне отвечает флаг visibility
const state = {
companies: [
{ id: 1, name: 'Hexlet', description: 'online courses', visibility: 'hidden' },
{ id: 2, name: 'Google', description: 'search engine', visibility: 'shown' },
{ id: 3, name: 'Facebook', description: 'social network', visibility: 'hidden' },
],
};
Где-то дальше, в слое отображения, происходит вывод этих данных с учетом флага. Технически задача решена, но у данного способа хранения есть существенные недостатки.
Начнем с главного. Данные на фронтенде не появляются из ниоткуда. Данные приложения хранятся на сервере, приходят с сервера и уходят на сервер. А сервер ничего про внешний вид не знает и знать не должен, это не касается данных. И тут возникает серьезная проблема. Если UI-состояние хранится внутри данных, то придется постоянно выполнять две вещи:
- Вводить дополнительную обработку для всех приходящих данных с сервера, добавляя туда UI-состояние.
- Вводить дополнительную обработку для всех данных, уходящих на сервер, удаляя из них все UI-состояние.
А подобных элементов отображения, как правило, значительно больше, чем один. Сюда можно отнести видимость модальных окон, сортировку, скрытие/раскрытие во всех возможных проявлениях, различные режимы (редактирование), подтверждения и многое другое. Все это придется не просто хранить внутри данных, но и постоянно помнить про необходимость дополнительной обработки.
Но это еще не все. Далеко не всегда весь набор данных обрабатывается одинаково. Возможно, что один набор данных выводится на странице в разных местах либо только частично. Это значит, что UI-состояние у разных элементов может быть разное, либо у каких-то элементов его может не быть вообще. Как поступать в таком случае? Игнорировать различия и добавлять всем одинаковый набор данных или усложнять логику и делать заполнение выборочным?
Из-за перечисленных проблем UI-состояние хранят отдельно от самих данных. Причем для каждой ситуации это будет свой набор данных. Например, для аккордеона состояние может выглядеть так:
const state = {
companies: [...],
uiState: {
accordion: [
{ companyId: 1, visibility: 'hidden' },
{ companyId: 2, visibility: 'shown' },
{ companyId: 3, visibility: 'hidden' },
],
},
};
Отметим несколько моментов:
companyId
нужен для связи с данными. Сами данные не дублируются. Подробнее о структуре данных в одном из следующих уроков.- UI-состояние может формироваться как в процессе работы приложения, так и на этапе инициализации при его запуске. Зависит от того, когда какой элемент появляется.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Вебинар «Как самостоятельно учиться»
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.