Як більше ніколи не повторювати ті самі помилки RxJs⚡

Пам'ятайте: .pipe () - це не .subscribe ()!

Ця стаття орієнтована на початківців, які намагаються підвищити свої знання про RxJ, але також можуть бути швидким оновленням чи посиланням для початківців для більш досвідчених розробників!

Сьогодні ми будемо тримати це коротко і прямо до справи!

В даний час я працюю в досить великій організації, у якій є декілька команд та проектів (понад 40 SPA), які перебувають у процесі міграції до Angular, а тому також RxJ.

Це чудова можливість зв’язатись із заплутаними частинами RxJ, про які легко забути, коли хтось освоїть API і замість цього зосередиться на реалізації функцій.

Функція “.subscribe ()”

Спостережувані RxJ представляють "рецепт" того, що ми хочемо зробити. Це декларативно, що означає, що всі операції та перетворення вказані повністю з самого початку.

Приклад спостережуваного потоку може виглядати приблизно так ...

Цей спостережуваний потік RxJs сам по собі буквально нічого не зробить. Для його виконання нам потрібно підписатися на нього десь у нашій кодовій базі!

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

Крім того, ми також можемо передавати об'єкт із властивостями, перерахованими вище. Такий об'єкт є реалізацією Observerінтерфейсу. Перевага спостерігача полягає в тому, що ми не повинні забезпечувати реалізацію або принаймні nullзаповнювач для обробників, які нас не цікавлять.

Розглянемо наступний приклад ...

У наведеному вище коді ми передаємо об'єктний літерал, який містить лише повний обробник, нормальні значення будуть ігноруватися, а помилки будуть пускати стек.

І в цьому прикладі ми передаємо обробник наступної помилки і завершуємо його як прямі аргументи функції Subscribe. Усі нереалізовані обробники повинні передаватися як нульові або невизначені, поки не дійдемо до аргументу, який нас цікавить.

Як бачимо, стиль вбудованого аргументу реалізації .subscribe()виклику функції є позиційним.

З мого досвіду, стиль вбудованих аргументів є найбільш поширеним у різних проектах та організаціях.

На жаль, багато разів ми можемо зіткнутися з реалізацією, як показано нижче ...

Наведений вище приклад містить надлишкові обробники як для обробників, так nextі errorдля обробників, які абсолютно нічого не роблять і могли бути замінені null.

Ще краще було б передати об'єкт спостерігача з реалізацією completeобробника, взагалі опустивши інші обробники!

“.Pipe ()” та оператори

Оскільки початківці звикли надавати три аргументи для передплати, вони часто намагаються реалізувати подібний шаблон при використанні подібних операторів у ланцюзі каналів.

Операторами RxJs, яких часто плутають з .subscribe()обробниками, є catchErrorі finalize. Вони обидва також служать однаковій меті - єдина відмінність полягає в тому, що вони використовуються в контексті конвеєра замість підписки.

Якщо ми хотіли б реагувати на повну подію кожної підписки спостережуваного потоку RxJs, ми могли б реалізувати finalizeоператор як частину самого спостережуваного потоку.

Таким чином, нам не потрібно залежати від розробників, щоб впроваджувати повні обробники у кожному окремому виклику .subscribe (). Пам’ятайте, на спостережуваний потік можна підписатися не раз!

Це підводить нас до остаточного і, мабуть, найбільш проблемного шаблону, з яким ми можемо зіткнутися при дослідженні різних баз коду: зайві оператори, додані при спробі слідувати за шаблоном .subscribe () у контексті .pipe ().

Крім того, ми можемо зустріти ще більш багатослівного кузена ...

Зверніть увагу, що ми перейшли від вихідного одного рядка до повних дев’яти рядків коду, який ми повинні прочитати та зрозуміти, коли хочемо виправити помилку або додати нову функцію.

Матеріали можуть стати ще більш складними в поєднанні з більш складними загальними типами Typescript, що може зробити весь блок коду ще більш загадковим (і, отже, витрачати більше нашого часу).

Рекапітуляція

  1. .subscribe()Метод приймає як об'єкт спостерігача і вбудовані обробники.
  2. Об'єкт спостерігача являє собою найбільш універсальний і стислий спосіб підписатися на спостережуваний потік.
  3. У разі , якщо ми хочемо йти в ногу зі рядний підписуються аргументів ( next, error, complete) ми можемо надати nullзамість обробника ми не потрібні.
  4. Ми повинні переконатись, що не намагаємося повторити .subscribe()шаблон при роботі з .pipe()операторами.
  5. Завжди прагніть максимально спростити код і усунути непотрібні надмірності!

Це воно! ✨

Сподіваюсь, вам сподобалась ця стаття і тепер ви краще зрозумієте, як підписатися на спостережувані матеріали RxJ з чітким, стислим виконанням!

Будь ласка, підтримайте цей посібник своїм ??? за допомогою кнопки плескати та допомогти йому поширитися на ширшу аудиторію? Крім того, не соромтеся запитувати мене, якщо у вас виникли запитання, використовуючи відповіді на статті або Twitter DMs @tomastrajan.

І ніколи не забувайте, майбутнє яскраве Починаючи проект Angular? Ознайомтесь із кутовим стартовим матеріалом NgRx!

Якщо ви зайшли так далеко, сміливо переглядайте деякі інші мої статті про розробку програмного забезпечення Angular та інтерфейсу взагалі ...

? ‍? ️ 7 підказок для підвищення продуктивності за допомогою кутових CLI та схем?

Г улара Schematics є інструментом документообігу для сучасного Інтернету - офіційне введення articlehac kernoon.com   Кращого способом Відмовитися RxJS спостережуваних в кутовому застосуванні!

Існує багато різних способів обробляти підписки на RxJS у програмах Angular, і ми збираємось вивчити їх… blog.angularindepth.com Загальний посібник із введення залежності від Angular 6+ - за умови надання проти постачальників: []?

L Інопланетян дізнатися , коли і як використовувати новий кутовий 6+ ін'єкцію залежностей механізму з новим синтаксисом providedIn зробити ... м edium.com Відповідь на дуже поширеному кутовому Питання: підписатися () проти | асинхронна труба

Більшість популярних бібліотек управління державами Angular, таких як NgRx, виставляють стан додатків у формі потоку… blog.angularindepth.com