⚡ Sådan gentages aldrig de samme RxJs-fejl igen mistakes

Husk: .pipe () er ikke .subscribe ()!

Denne artikel er rettet mod begyndere, der forsøger at øge deres RxJs-viden, men kan også være en hurtig opdatering eller en reference, der skal vises til begyndere for mere erfarne udviklere!

I dag skal vi holde det kort og lige til det punkt!

I øjeblikket arbejder jeg i en ret stor organisation en hel del teams og projekter (mere end 40 SPA'er), der er i færd med at migrere til Angular og derfor også RxJs.

Dette repræsenterer en fantastisk mulighed for at komme i kontakt med de forvirrende dele af RxJ'er, som det kan være let at glemme, når man mestrer API'erne og fokuserer på implementeringen af ​​funktionerne i stedet.

Funktionen ".subscribe ()"

RxJs observerbare repræsenterer en “opskrift” på, hvad vi ønsker at ske. Det er deklarativ, hvilket betyder, at alle operationer og transformationer er specificeret i deres helhed fra starten.

Et eksempel på en observerbar strøm kan se sådan ud ...

Denne RxJs observerbare strøm vil bogstaveligt talt ikke gøre noget i sig selv. For at udføre det er vi nødt til at abonnere på det et eller andet sted i vores codebase!

I eksemplet ovenfor leverede vi kun en handler til de værdier, der udsendes af de observerbare. Abonnementsfunktionen accepterer op til tre forskellige argumenter for at håndtere næste værdi, fejl eller fuldstændig begivenhed.

Derudover kunne vi også videregive et objekt med ovenstående egenskaber. Et sådant objekt er en implementering af Observergrænsefladen. Fordelen ved observatør er, at vi ikke behøver at levere implementering eller i det mindste en nullpladsholder til de håndterere, vi ikke er interesseret i.

Overvej følgende eksempel ...

I koden ovenfor sender vi et objekt bogstaveligt, som kun indeholder komplet handler, de normale værdier ignoreres, og fejl vil boble op ad stakken.

Og i dette eksempel sender vi håndtereren af ​​den næste fejl og fuldfører den som direkte argumenter for abonnementsfunktionen. Alle ikke-implementerede håndterere skal overføres som null eller udefineret, indtil vi kommer til det argument, vi er interesseret i.

Som vi kan se, er den indbyggede argumentstil for implementering af et .subscribe()funktionsopkald positionel.

Efter min erfaring er stilen med integrerede argumenter den, der er mest almindelig i forskellige projekter og organisationer.

Desværre kan vi mange gange støde på implementering som følgende ...

Eksemplet ovenfor indeholder overflødige håndterere til begge nextog errorhåndterere, der gør nøjagtigt ingenting og kunne have været erstattet af null.

Endnu bedre ville det være at passere observatørobjektet med completehandlerimplementeringen og udelade andre handlere helt!

“.Pipe ()” og operatørerne

Da begyndere er vant til at give tre argumenter for at abonnere, prøver de ofte at implementere et lignende mønster, når de bruger lignende operatører i rørkæden.

RxJs-operatører, som ofte er forvekslet med .subscribe()håndtererne, er catchErrorog finalize. De tjener begge et lignende formål - den eneste forskel er, at de bruges i røret i stedet for abonnementet.

Hvis vi gerne vil reagere på den komplette begivenhed i hvert abonnement på den observerbare RxJs-strøm, kan vi implementere finalizeoperatøren som en del af selve den observerbare stream.

På den måde behøver vi ikke være afhængige af udviklerne for at implementere komplette håndterere i hvert eneste .subscribe () -opkald. Husk, at den observerbare strøm kan abonneres på mere end én gang!

Dette bringer os til det endelige og uden tvivl mest problematiske mønster, vi kan støde på, når vi udforsker forskellige kodebaser: overflødige operatorer tilføjet, når de prøver at følge .subscribe () -mønster i .pipe () -konteksten.

Vi kan også støde på dens endnu mere detaljerede fætter ...

Bemærk, at vi er gået fra den oprindelige enkeltlinie til de fulde ni linjer kode, som vi skal læse og forstå, når vi vil rette en fejl eller tilføje en ny funktion.

Ting kan blive endnu mere komplekse, når de kombineres med mere komplekse generiske Typescript-typer, hvilket kan gøre hele kodeblokken endnu mere mystisk (og dermed spilde mere af vores tid).

Rekapitulation

  1. Den .subscribe()metode accepterer både observatøren objekt og inline handlere.
  2. Observatørobjektet repræsenterer den mest alsidige og koncise måde at abonnere på en observerbar strøm på.
  3. I tilfælde, vi ønsker at gå med inline abonnerer argumenter ( next, error, complete) vi kan give nulli stedet for en handler vi ikke har brug for.
  4. Vi skal sørge for, at vi ikke prøver at gentage .subscribe()mønsteret, når vi beskæftiger os med .pipe()og operatører.
  5. Stræb altid med at holde koden så enkel som muligt og fjerne unødvendige afskedigelser!

Det er det! ✨

Jeg håber, du har haft glæde af denne artikel og nu får en bedre forståelse af, hvordan du abonnerer på RxJs observerbare med ren, kortfattet implementering!

Støt venligst denne guide med din ??? ved hjælp af klappeknappen og hjælpe den med at sprede sig til et bredere publikum? Tøv ikke med at pinge mig, hvis du har spørgsmål ved hjælp af artikelsvaret eller Twitter DMs @tomastrajan.

Og glem aldrig, fremtiden er lys Start af et kantet projekt? Tjek Angular NgRx Material Starter!

Hvis du er kommet så langt, er du velkommen til at tjekke nogle af mine andre artikler om Angular og frontend softwareudvikling generelt ...

? ‍? ️ De 7 Pro-tip til at blive produktive med kantede CLI & skemaer?

En g ular Skema er en arbejdsproces værktøj til det moderne internet - officiel introduktion articlehac kernoon.com   Den bedste måde at Afmeld RxJS kan observeres i den kantede applikationer!

Der er mange forskellige måder, hvorpå man håndterer RxJS-abonnementer i kantede applikationer, og vi vil udforske deres ... blog.angularindepth.com Samlet guide til vinkel 6+ afhængighedsinjektion - forudsat i forhold til udbydere: []?

L et lærer hvornår og hvordan man bruger en ny bedre Angular 6+ afhængighedsinjektionsmekanisme med ny forudsatIn syntaks for at gøre ... m edium.com Det ultimative svar på det meget almindelige kantede spørgsmål: abonner () vs | asynkroniseringsrør

De fleste af de populære Angular state management-biblioteker som NgRx udsætter applikationstilstand i en form af en strøm af ... blog.angularindepth.com