⚡ Hogyan soha ne ismételjük meg ugyanazokat az RxJ hibákat?

Ne feledje: .pipe () nem .subscribe ()!

Ez a cikk azoknak a kezdőknek szól, akik megpróbálják bővíteni az RxJ-k ismereteit, de gyors frissítésként vagy referenciaként is szolgálhat a kezdők számára a tapasztaltabb fejlesztők számára!

Ma röviden és egyenesen a lényegre törekszünk!

Jelenleg egy meglehetősen nagy szervezetben dolgozom, jó néhány csapatban és projektben (több mint 40 SPA), amelyek áttérnek az Angularra és ezért az RxJ-kre is.

Ez nagyszerű lehetőséget kínál a kapcsolatfelvételre az RxJ zavaró részeivel, amelyeket könnyen el lehet felejteni, ha valaki elsajátítja az API-kat, és inkább a funkciók megvalósítására összpontosít.

A „.subscribe ()” függvény

A megfigyelhető RxJ-k „receptet” jelentenek annak, amire szeretnénk történni. Ez deklaratív, ami azt jelenti, hogy az összes műveletet és transzformációt teljes egészében megadják az indulástól kezdve.

Egy megfigyelhető folyam példája ilyennek tűnhet…

Ez az RxJ-k által megfigyelhető adatfolyam szó szerint semmit sem fog tenni önmagában. A végrehajtáshoz fel kell iratkoznunk rá valahol a kódbázisunkba!

A fenti példában csak az észlelhető által kibocsátott értékekhez adtunk kezelőt. Maga az előfizetési függvény legfeljebb három különböző argumentumot fogad el a következő érték, hiba vagy teljes esemény kezeléséhez.

Emellett átadhatnánk egy objektumot is a fent felsorolt ​​tulajdonságokkal. Egy ilyen objektum az Observerinterfész megvalósítása. A megfigyelő előnye, hogy nem kell megvalósítást vagy legalább nullhelyőrzőt nyújtanunk az általunk nem érdekelt kezelők számára.

Tekintsük a következő példát ...

A fenti kódban egy olyan objektum literált adunk át, amely csak teljes kezelőt tartalmaz, a normál értékeket figyelmen kívül hagyjuk, és hibák bugyborékolnak.

Ebben a példában átadjuk a következő hiba kezelőjét, és kiegészítjük az előfizetés függvény közvetlen argumentumaként. Minden megvalósítatlan kezelőt nullának vagy definiálatlannak kell átadni, amíg el nem jutunk az általunk érdekelt érvig.

Mint láthatjuk, a .subscribe()függvényhívás végrehajtásának inline argumentumstílusa pozicionális.

Tapasztalataim szerint az inline argumentumok stílusa a legelterjedtebb a különböző projektekben és szervezetekben.

Sajnos sokszor találkozhatunk a következő megvalósítással ...

A fenti példa redundáns kezelőket tartalmaz mindkettőhöz, nextvalamint errorazokhoz a kezelőkhöz, amelyek pontosan semmit sem tesznek, és helyettesíthetők lettek volna null.

Még jobb, ha a megfigyelő objektumot completeátadná a kezelő megvalósításával, a többi kezelőt teljesen kihagyva!

A „.pipe ()” és az operátorok

Mivel a kezdők három érvet szoktak megadni a feliratkozáshoz, gyakran megpróbálnak hasonló mintát megvalósítani, amikor hasonló operátorokat használnak a csővezetékben.

Az RxJs operátorok, akiket gyakran összetévesztenek a .subscribe()kezelőkkel, az catchErrorés finalize. Mindkettő hasonló célt szolgál - az egyetlen különbség az, hogy az előfizetés helyett a cső kontextusában használják őket.

Abban az esetben, ha szeretnénk reagálni az RxJ-k megfigyelhető adatfolyamának minden előfizetésének teljes eseményére, megvalósíthatjuk az finalizeoperátort a megfigyelhető adatfolyam részeként.

Így nem kell a fejlesztőktől függenünk, hogy minden egyes .subscribe () hívásban komplett kezelőket kell megvalósítanunk. Ne feledje, hogy a megfigyelhető adatfolyamra többször is fel lehet iratkozni!

Ezzel eljutunk a végső és vitathatatlanul legproblémásabb mintához, amellyel különféle kódbázisok feltárása során találkozhatunk: redundáns operátorok adódtak hozzá, amikor megpróbáltuk követni a .subscribe () mintát a .pipe () kontextusban.

Találkozhatunk még bőbeszédűbb unokatestvérével…

Figyeljük meg, hogy az eredeti egyetlen sorból a kilenc teljes kódsorba léptünk át, amelyet el kell olvasnunk és meg kell értenünk, ha hibát akarunk kijavítani, vagy új funkciót akarunk hozzáadni.

A dolgok még bonyolultabbá válhatnak, ha összetettebb általános Typescript típusokkal kombinálják, amelyek az egész kódblokkot még titokzatosabbá tehetik (és ezzel több időnket pazarolják).

Összegzés

  1. A .subscribe()módszer mind a megfigyelő objektumot, mind az inline kezelőket elfogadja.
  2. A megfigyelő objektum a megfigyelhető folyamra való feliratkozás legsokoldalúbb és legtömörebb módja.
  3. Abban az esetben, azt akarjuk, hogy menjen el a inline feliratkozás érvek ( next, error, complete) biztosítani tudjuk nulla helyén egy felvezető nincs szükségünk.
  4. Gondoskodnunk kell arról, hogy ne próbáljuk megismételni a .subscribe()mintát a kezelőkkel .pipe()és az operátorokkal.
  5. Mindig törekedjen arra, hogy a kód a lehető legegyszerűbb legyen, és távolítsa el a felesleges feleslegeket!

Ez az! ✨

Remélem, tetszett Önnek ez a cikk, és most jobban meg fogja érteni, hogyan kell feliratkozni az RxJs megfigyelhetőire tiszta, tömör megvalósítással!

Kérjük, támogassa ezt az útmutatót a ??? a taps gomb használatával, és elősegíti, hogy szélesebb közönség számára is elterjedjen? Ne habozzon pingálni, ha bármilyen kérdése van a cikkre adott válaszok vagy a Twitter DMs @tomastrajan segítségével.

És soha ne felejtsd el, a jövő fényes Szögletes projekt elindítása? Nézze meg az Angular NgRx Material Starter terméket!

Ha eddig eljutott, nézze meg bátran az Angular és a frontend szoftverfejlesztésről szóló további cikkeket ...

? ‍? ️ A 7 profi tipp, hogy produktívabbá váljon a szögletes CLI és sémák segítségével?

A g ular Schematics egy munkafolyamat-eszköz a modern internet számára - hivatalos bevezetés Articlehac   kernoon.com A szögletes alkalmazásokban megfigyelhető RxJS-leiratkozás legjobb módja!

Sokféle módon kezelhetjük az RxJS-előfizetéseket az Angular alkalmazásokban, és meg fogjuk vizsgálni a… blog.angularindepth.com Teljes útmutató a szögletes 6+ függőségi injekcióhoz - biztosítottIn vs szolgáltatók: []?

L et megtanulhatja, hogy mikor és hogyan kell használni az új jobb szögletes 6+ függőség injekció mechanizmus új providedIn szintaxis, hogy a ... m edium.com A végső válasz a nagyon elterjedt szögletes kérdés: feliratkozás () vs | aszinkron Pipe

A legnépszerűbb szögletes állapotkezelő könyvtárak, mint például az NgRx, az alkalmazás állapotát… blog.angularindepth.com formájában tárják fel.