Как выбрать между Angular Signals и RxJS

Signals и RxJS дополняют друг друга, но дают разные гарантии. Signal отвечает на вопрос: «Какое значение я получу, если прочитаю его сейчас?». Observable описывает значения или события, которые поступают со временем, а также правила подписки, порядка, отмены, ошибок и завершения. Надежная архитектура Angular исходит из этой семантики, а не пытается объявить одно средство победителем.

На практике решение часто принимают для отдельной части системы. Например, модуль может координировать поиск через RxJS, представлять последний результат и состояние запроса через Signals, а видимую модель вычислять с помощью computed. Архитектура работает, когда у каждой границы один ответственный и сохраняется важное для пользователя поведение. Она дает сбой, если преобразования становятся автоматической привычкой и скрывают лишние подписки, потерянные события или два конкурирующих состояния.

Ниже приведены критерии такого выбора. Они дополняют наши материалы об управлении состоянием в сложных продуктах на Angular, быстродействии приложений с большими массивами данных и более широком вопросе о том, когда Angular уместен для платформы.

Отталкивайтесь от поведения, а не от моды

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

Выбирайте Signals, если потребитель читает текущее значение, доступное синхронно, а Angular должен отслеживать места чтения. RxJS уместен, когда значение имеет сама последовательность: действия пользователя, ответы сети, повторные попытки, сообщения WebSocket, таймеры или команды, результат которых зависит от порядка и отмены. Если временной процесс должен показывать актуальный срез, создайте между двумя моделями явный переход.

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

Signals — для состояния, доступного здесь и сейчас

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

Применяйте computed Signals для чистых производных: отфильтрованных строк, разрешений на основе идентичности пользователя и политики доступа, итогов, сводок проверки или моделей представления, собранных из меньших значений. Такие вычисления ленивы, сохраняют предыдущий результат, а Angular отслеживает лишь зависимости, прочитанные во время последнего запуска. Производная должна быть однозначной: одинаковые входные данные всегда должны давать одинаковый результат.

Signal только для чтения запрещает вызывающему коду применять set или update, но не делает вложенный объект неизменяемым. Если обнаружение изменений опирается на ссылочную тождественность, предпочитайте создание нового значения. Собственное правило равенства добавляйте только после измерения лишней работы. Глубокое сравнение может стоить дороже перерисовки, которой оно позволяет избежать и скрыть модель, которая меняет объекты на месте.

RxJS нужен, когда значение имеет ход во времени

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

Способ работы с внутренними потоками следует выбирать по правилу продукта. switchMap отменяет потерявшую актуальность внутреннюю подписку; concatMap ставит работу в очередь; exhaustMap отбрасывает новые сигналы запуска, пока идет текущая операция; mergeMap разрешает параллельное выполнение, которое должно быть безопасным. Это деловые решения, если отмена способна потерять команду, а одновременное выполнение — провести платеж дважды.

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

Не выполняйте побочные действия в computed

Функция computed должна вычислять, а не выполнять действия. HTTP-запросы, запись в хранилище, аналитика, навигация, таймеры и изменение данных внутри производной делают момент ее оценки заметным и ненадежным. Из-за ленивого выполнения непрочитанное значение может никогда не запуститься; из-за повторного вычисления побочное действие может произойти больше раз, чем ожидалось. Сохраняйте вычисляемое состояние чистым.

Используйте effect как настоящий мост к императивному, нереактивному API: для сохранения выбранных настроек, обновления библиотеки диаграмм, добавления особого поведения DOM или отправки строго контролируемых диагностических данных. Производные значения лучше строить через computed, а действия пользователя — через явные методы команд. Копирование одного Signal в другой с помощью effect обычно указывает, что у состояния неверный владелец.

Для каждого effect нужно продумать жизненный цикл. Определите, кому он принадлежит — компоненту, службе модуля или корню приложения; зарегистрируйте очистку таймеров, слушателей и продолжительной работы; не создавайте случайных зависимостей из-за попутного чтения. Если асинхронное действие способно пережить запустившее его значение, добавьте отмену или защиту от устаревшего результата. Сам по себе следующий запуск не делает предыдущую работу безопасной.

Серверные данные — это больше, чем последнее значение

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

Механизм запроса выбирайте по ходу работы. RxJS хорошо подходит для запросов с задержкой после ввода, зависимых вызовов, повторов, периодического опроса, общих потоков и явно заданной параллельности. API ресурсов Angular могут представлять асинхронные зависимости через Signals вместе со значением, состоянием, признаком загрузки и ошибкой. Ресурс уместен для чтения; изменения требуют отдельных команд, идемпотентности, согласования результата и понятного сообщения пользователю.

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

Ограничивайте места перехода между моделями

Преобразуйте модель один раз на осознанно выбранной границе модуля или службы, а не каждый раз в компонентах. toSignal немедленно подписывается на Observable, поэтому создайте его в одном месте и повторно используйте полученный Signal. Задайте начальное значение, допускайте undefined до первого события или применяйте requireSync лишь тогда, когда синхронное событие действительно гарантировано. Точно знайте, где уничтожается подписка и как ошибка Observable проявится при чтении Signal.

toObservable представляет Signal как поток установившегося состояния. Внутри он использует effect, поэтому обновления после подписки поступают асинхронно, а несколько последовательных синхронных записей в Signal могут дать лишь последнее значение. Для состояния это правильно, но для журнала действий или очереди команд — нет. Если имеет значение каждый случай, моделируйте его как событие с самого начала, а не восстанавливайте события из изменяемого состояния позднее.

Хорошая граница скрывает механизм. Компоненты читают небольшой набор Signals и вызывают методы, выражающие намерение; фасад внутри может координировать потоки Observable, ресурсы и команды. Не возвращайте для одного понятия одновременно изменяемые Signals и объекты Subject. Укажите, что именно представляет граница: длительное состояние, кратковременное уведомление или операцию, ведь их поведение при ошибках и повторной выдаче должно различаться.

Оставьте один первоисточник

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

Различайте исходное состояние, производное состояние, события и команды. Исходное состояние меняет только его владелец. Производное вычисляется и никогда не исправляется отдельно. Событие сообщает о том, что уже произошло, и может быть кратковременным. Команда выражает намерение и может выполниться, завершиться ошибкой или быть отменена. Многие споры «Signals или RxJS» исчезают, когда эти понятия перестают жить в одном универсальном хранилище.

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

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

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

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

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

• Начинайте с семантики: определите, нужны ли потребителям текущее значение, каждое упорядоченное событие, отмена, управляемая параллельность, восстановление после ошибки или содержательное завершение.
• Назначьте владельца состояния Signal: держите изменяемые Signals за одной ответственной границей, открывайте состояние лишь для чтения, стройте чистые производные через computed и не меняйте глубокие объекты в обход смены ссылки.
• Описывайте время средствами RxJS: выбирайте switchMap, concatMap, exhaustMap или mergeMap по правилу продукта, а затем определяйте повторы, ошибки, завершение, совместное использование и освобождение ресурсов.
• Локализуйте побочные действия: не добавляйте их в computed, применяйте effect только на императивных границах, регистрируйте очистку и не позволяйте устаревшему завершению асинхронной работы изменить состояние.
• Моделируйте серверные данные: учитывайте тождественность запроса, первую и повторную загрузку, ошибку, актуальность, кеш, сброс, авторизацию, оптимистические изменения и окончательное согласование.
• Создайте один переход и проверьте его жизненный цикл: преобразуйте модель на границе службы, опишите начальное значение и поведение ошибки, не объединяйте события, важные по отдельности, и проверьте отмену, уничтожение, повторную подписку и число ресурсов.