Как спроектировать управление состоянием в сложном продукте Angular

Управление сложным состоянием сначала является задачей моделирования, а уже затем выбором библиотеки. Развёрнутая панель, несохранённый счёт, личность вошедшего пользователя, кэшированный товар, попытка платежа и уведомление в реальном времени различаются достоверным источником, владельцем, сроком жизни, правилами одновременных действий, чувствительностью и поведением при отказе. Если поместить всё в одно глобальное хранилище, возникнет скрытый слой интеграции. Если оставить всё внутри компонентов, правила будут дублироваться, а многоэтапная работа распадётся на части.

Начинайте с перечня состояний, связанного с настоящими путями пользователей. Определите, какая система является достоверным источником, кто может записывать и кому нужно читать, когда значение возникает и перестаёт действовать, как оно устаревает, что переживает навигацию или перезагрузку и что происходит при отмене, повторе, конфликте или частичном отказе. Только после этого выбирайте сигналы компонента, службу функциональной области, RxJS, кэш серверных данных, NgRx Signal Store или NgRx Store. Архитектура должна облегчать изменение и объяснение продукта, а не просто собирать объекты в одном месте.

Классифицируйте состояние до выбора средств

Классифицируйте состояние по нескольким признакам. Достоверный источник показывает, где находится истина: в браузере, на сервере, в URL или у другого клиента. Объём указывает на компонент, функциональную область, маршрут, сеанс, учётную запись или клиента системы. Срок жизни простирается от одного взаимодействия до длительной истории бизнеса. Также запишите чувствительность, требования к согласованности и свежести, читателей, авторов, условия сброса и то, важны ли порядок или каждое событие. Эти свойства надёжнее выявляют правильные границы, чем размер приложения.

Отделяйте исходное состояние от вычисленного. Храните наименьший набор достоверных фактов, а итоги, сообщения проверки, отфильтрованные подборки, разрешения и варианты представления вычисляйте чистыми функциями выборки или computed(). Копирование вычисленного значения в другой записываемый сигнал создаёт потребность в синхронизации и неоднозначность владельца. Angular рекомендует вычисляемые значения для производных данных, а эффекты — для согласования с императивными, нереактивными API, а не для переноса состояния между сигналами.

Преобразуйте перечень в запись решения для каждой важной группы состояний: владелец, API, путь изменения, срок жизни, сброс, модель ошибок, наблюдение, тесты и перенос или возврат. Добавьте конкретные примеры: «черновик оформления заказа переживает смену маршрута, но истекает через 24 часа» или «сведения о личности приходят с сервера и очищаются как одно неделимое действие при выходе». Пересматривайте карту при изменении команд, процессов, регулирования, нагрузки или требований к работе без сети. Случайное глобальное состояние становится всё труднее удалить с появлением каждого нового читателя.

Храните местное состояние в его естественных границах

Состояние представления должно находиться рядом с интерфейсом, которому принадлежит: развёрнутые строки, выбранные вкладки, временные фильтры, фокус, направление сортировки, открытое диалоговое окно и черновик ввода, не имеющий значения за пределами маршрута. Сигналы компонента или функциональной области прямо выражают текущие значения и вычисленные представления. Держите записываемые сигналы закрытыми, наружу предоставляйте состояние только для чтения и используйте методы с выразительным названием намерения, такие как selectInvoice() или resetFilters(), вместо произвольной записи из шаблонов и потребителей.

Поднимайте состояние выше лишь тогда, когда появляется конкретный второй владелец или срок жизни перерастает компонент. Поставщик зависимости на уровне маршрута может согласовывать соседние компоненты, не превращая потребность одной функциональной области в общий объект всего приложения. Её внешний слой может скрыть использование сигналов, RxJS или хранилища и предоставить узкую модель чтения вместе с командами. Осознанно определяйте уровень поставщика: корневая служба живёт весь сеанс приложения и может дольше ожидаемого удерживать устаревшие данные, подписки и состояние конкретного пользователя.

Не путайте состояние доступности или навигации с одноразовой визуальной деталью. Восстановление фокуса, озвучивание ошибок проверки, смысл развёртывания, фильтры в URL и история браузера могут требовать согласования за пределами одного узла DOM. Решите, должен ли URL быть достоверным источником для поисков и вкладок, которыми можно поделиться. Проверяйте уничтожение и повторное создание, навигацию назад и вперёд, несколько одновременных экземпляров этой части продукта, выход, смену языка и выгрузку отложенного маршрута. Цель — самые узкие границы, которые всё ещё сохраняют договор с пользователем.

Представляйте процессы как явные переходы между состояниями

Процесс бизнеса — это больше, чем набор логических флагов. Опишите осмысленные состояния и переходы: платёж может не выполняться, проходить проверку, отправляться, ожидать подтверждения, завершиться успешно, потерпеть отказ с возможностью повтора или остаться с неизвестным результатом после истечения времени ожидания. Невозможные сочетания вроде loading && succeeded && error исчезают, когда модель представляет лишь одну допустимую фазу. Разделяйте события бизнеса, команды, эффекты и итоговое состояние, чтобы команда могла объяснить, почему экран оказался в текущем состоянии.

Проектируйте отказ и восстановление как полноценные переходы. Записывайте, безопасно ли повторять операцию, принял ли её сервер, какой ключ идемпотентности её определяет и останавливает ли отмена только подписку браузера или также основную работу. Сохраняйте ввод пользователя независимо от состояния отправки. Для опережающих изменений удерживайте достаточно сведений, чтобы подтвердить, сверить или компенсировать результат: бездумный возврат может стереть более новую правку или изменение на сервере.

Используйте функцию перехода состояния, метод Signal Store, функцию службы или автомат состояний в соответствии со сложностью процесса, но сохраняйте язык переходов предметным. Не позволяйте компонентам согласовывать многоэтапный процесс через подписки друг на друга. Добавляйте к эффектам идентификаторы связи и операции и делайте повторные команды безопасными. Проверяйте таблицу переходов, включая двойные нажатия, поздние ответы, навигацию во время отправки, потерю авторизации, конфликт, исчерпание повторов, восстановление без сети и обновление страницы после неопределённого результата.

Относитесь к серверным данным как к кэшу с версиями

Данные, полученные из API, являются местным кэшем достоверного серверного источника, а не постоянной клиентской истиной. Опишите ключ запроса, параметры, результат, свежесть, состояние загрузки и ошибки, время последнего успешного обновления, условия отмены действительности и правила повторного получения. Различайте «никогда не загружалось», «обновляется с пригодными данными» и «ошибка с устаревшими данными». Один флаг loading отбрасывает сведения, необходимые для устойчивого интерфейса и разумного восстановления.

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

Храните транспортные подробности и серверные DTO на границе. Проверяйте ответы, преобразуйте их в устойчивые предметные типы и сохраняйте курсоры страниц, версии, ETag или временные отметки, необходимые для согласованности. Решите, могут ли передача при SSR, повторное использование маршрута, кэш браузера и кэш приложения каждый отдельно хранить ответ; несколько слоёв кэша требуют совместимых ключей и отмены действительности. Измеряйте долю попаданий, лишние запросы, чтение устаревших данных, время от изменения до его появления, размер данных и восстановление после отказа до добавления ещё одного слоя кэширования.

Нормализуйте сущности лишь ради ощутимой согласованности

Нормализуйте сущности, когда одна и та же личность или вещь появляется в нескольких подборках, обновления приходят независимо либо множество представлений должны наблюдать одну согласованную запись. Храните сущности по устойчивому идентификатору, а упорядоченные перечни идентификаторов или принадлежность к запросу — отдельно. Функции выборки могут собирать представление, необходимое каждому экрану. Это уменьшает число противоречивых копий и делает целевые обновления предсказуемыми, особенно при совместном редактировании или событиях от сервера.

Нормализация имеет цену: больше опосредованных связей, обработки отношений, работы функций выборки, очистки неиспользуемых данных и решений о неполных записях. Не нормализуйте одноразовые результаты поиска, неизменяемые снимки, небольшие наборы настроек или совокупные данные, для которых важна определённая сервером форма. Не считайте две записи одинаковыми лишь из-за общего числового идентификатора, если различаются их принадлежность клиенту системы, тип, версия, отфильтрованные по разрешениям поля или временной промежуток.

Определите правила объединения до поступления частичных ответов. Решите, означает ли отсутствующее поле неизвестное, неизменённое, скрытое или удалённое значение; как версии упорядочивают обновления, пришедшие не по очереди; и когда сущность можно удалить. Храните состояние запроса вне записей сущностей, чтобы отказ одной подборки не помечал пригодную для повторного использования сущность ошибочной везде. Проверяйте удаление, потерю разрешения, наложение страниц, временные идентификаторы, опережающее создание, изменения связей, развитие схемы и два представления, получающие обновления в разном порядке.

Сделайте одновременность асинхронных действий решением о поведении продукта

Операторы управления одновременными действиями определяют поведение продукта. В поиске самый новый запрос обычно заменяет предыдущий; при сохранении последовательности правок порядок может быть важен; для предотвращения повторного оформления заказа новые действия иногда следует игнорировать, пока идёт работа; для независимых загрузок может быть правильным ограниченное параллельное выполнение. Выбирайте отмену, очередь, игнорирование или объединение по договору с пользователем, а затем явно отражайте правило в названиях, тестах, состоянии загрузки и диагностических данных.

Отделяйте потоки событий от текущего состояния. Сигналы хорошо подходят для синхронно доступных текущих значений и вычисленных представлений; RxJS — для времени, отмены, регулирования поступления и сочетания множества событий. Осознанно определите границу взаимодействия со средствами Angular. toSignal() подписывается сразу, поэтому его следует создать один раз и использовать повторно; takeUntilDestroyed() связывает подписку со сроком жизни владельца. Не выполняйте преобразование каждый раз в шаблонах и не используйте эффект как самодельную последовательность асинхронных операций.

Каждый асинхронный путь требует правил ошибки и завершения. Избегайте вложенных подписок, неограниченных повторов и потоков, живущих дольше владельца. Решите, что происходит, когда параметры меняются во время запроса, компонент уничтожается, сеть отвечает с опозданием, WebSocket повторно соединяется после пропуска событий или время операции истекает уже после её подтверждения сервером. Для зависящей от порядка логики проверяйте виртуальное время или управляемое расписание и испытывайте поведение при всплеске ввода, а не только при одном событии.

Храните постоянно меньше состояния, добавляя версии и срок действия

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

Добавляйте к каждому сохранённому набору данных версию схемы, время создания и окончания действия, границы личности или клиента системы и стратегию переноса. Проверяйте данные при чтении: хранилище является недоверенной границей и может содержать старое, повреждённое, изменённое вручную или принадлежащее другой области значение. Очищайте его при выходе, смене учётной записи, отзыве согласия или несовместимом выпуске. Явно согласовывайте работу нескольких вкладок и не позволяйте устаревшей вкладке восстановить данные, удалённые более новым сеансом.

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

Проектируйте состояние так, чтобы его можно было объяснить, проверить и восстановить

Модель состояния должна отвечать на вопрос «что произошло?» без отладчика, подключённого к устройству пользователя. Называйте команды, события, переходы, функции выборки и эффекты языком предметной области. Записывайте в структурированные диагностические сведения идентификатор операции, источник, длительность, результат, повтор, отмену, итог обращения к кэшу и версию состояния, исключая секреты и личное содержимое. При необходимости используйте Angular DevTools, средства хранилища или узкую внутреннюю диагностику, но закладывайте наблюдение в границы, а не полагайтесь на сериализованную копию всего хранилища.

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

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

• Назовите каждую границу: до выбора библиотеки запишите достоверный источник, владельца, объём, срок жизни, читателей, авторов, свежесть, чувствительность, сброс и поведение при отказе.
• Не расширяйте состояние сверх его договора: используйте сигналы компонента или возможности для представления, поставщиков маршрута для ограниченного согласования, а глобальное состояние — лишь для доказанных потребностей всего продукта.
• Явно моделируйте переходы: представляйте допустимые фазы процесса, повтор, отмену, конфликт, неопределённый результат, компенсацию и идемпотентность вместо сочетания несвязанных флагов.
• Относитесь к серверным данным как к кэшу: определите тождество запроса, свежесть, отмену действительности, согласование изменений, объединение повторов, очистку личных данных и поведение устаревших сведений.
• Выбирайте одновременность по намерению: сделайте отмену, очередь, игнорирование во время активной работы, ограниченное параллельное выполнение, порядок, поздние ответы, срок жизни и обработку ошибок частью решения о продукте.
• Храните и диагностируйте осознанно: уменьшайте объём записанных данных, добавляйте версию и срок действия, проверяйте при восстановлении, наблюдайте переходы без чувствительного содержимого и предусмотрите перенос, сброс и возврат.