⚡ Как никога повече да не се повтарят същите грешки на RxJs⚡

Запомнете: .pipe () не е .subscribe ()!

Тази статия е насочена към начинаещите, които се опитват да увеличат своите знания за RxJ, но могат да бъдат и бързо опресняване или справка за показване на начинаещи за по-опитни разработчици!

Днес ще го държим кратко и направо по същество!

В момента работя в доста голяма организация, доста екипи и проекти (над 40 SPA), които са в процес на миграция към Angular и следователно също RxJ.

Това представлява чудесна възможност да се свържете с объркващите части на RxJ, които лесно може да се забравят, след като човек овладее API и вместо това се фокусира върху изпълнението на функциите.

Функцията „.subscribe ()“

Наблюдаемите RxJ представляват „рецепта“ на това, което искаме да се случи. Това е декларативно, което означава, че всички операции и трансформации са посочени изцяло от самото начало.

Пример за наблюдаем поток може да изглежда нещо подобно ...

Този наблюдаем поток RxJs няма да направи буквално нищо сам по себе си. За да го изпълним, трябва да се абонираме за него някъде в нашата кодова база!

В горния пример предоставихме манипулатор само за стойностите, излъчвани от наблюдаемото. Самата функция за абониране приема до три различни аргумента на манипулатора следваща стойност, грешка или пълно събитие.

Освен това бихме могли да предадем и обект с изброените по-горе свойства. Такъв обект е изпълнение на Observerинтерфейса. Предимството на наблюдателя е, че не е необходимо да осигурим изпълнение или поне nullрезервоар за манипулаторите, от които не се интересуваме.

Помислете за следния пример ...

В горния код предаваме обектен литерал, който съдържа само пълен манипулатор, нормалните стойности ще бъдат игнорирани и грешките ще изпъкнат в стека.

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

Както виждаме, вграденият стил на аргумент за изпълнение на .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 и схеми?

Един грам народен Схеми представлява работния процес, инструмент за съвременната мрежа - официалното пускане на пазара articlehac kernoon.com   най-добрият начин да се отпишете RxJS наблюдават в ъгловата приложения!

Има много различни начини за обработка на RxJS абонаменти в Angular приложения и ние ще проучим техните ... blog.angularindepth.com Общо ръководство за инжектиране на ъглова зависимост 6+ - предоставено в срещу доставчици: []?

Да научим кога и как да използваме новия по-добър механизъм за впръскване на зависимостта Angular 6+ с нов предоставен синтаксис, за да направим ... m edium.com Крайният отговор на много често срещания ъглов въпрос: абонамент () срещу | асинхронна тръба

Повечето от популярните библиотеки за управление на Angular state като NgRx излагат състоянието на приложението под формата на поток от ... blog.angularindepth.com