Як обрати між 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 лише на імперативних межах, реєструйте очищення й не дозволяйте застарілому завершенню асинхронної роботи змінити стан.
• Моделюйте серверні дані: ураховуйте тотожність запиту, перше й повторне завантаження, помилку, актуальність, кеш, скидання, авторизацію, оптимістичні зміни та остаточне узгодження.
• Створіть один перехід і перевірте його життєвий цикл: перетворюйте модель на межі служби, опишіть початкове значення та поведінку помилки, не об’єднуйте події, важливі окремо, і перевірте скасування, знищення, повторну підписку та кількість ресурсів.