Det kommer ikke som nogen overraskelse for nogen, at JavaScript er overalt.
Her på Imaginær sky, de fleste af de projekter, vi er involveret i, bruger det som hovedsprog. Mit sidste projekt var en ret stor applikation, der involverede de sædvanlige skyldige i JavaScript-økosystem. Vi brugte en React front-end og en Node.js back-end stack.
Da vi havde brug for at definere en stak til dette projekt, på grund af dets karakter af at involvere en masse visuel præsentation og 3D-modellering, præsenterede React sig selv som et no-brainer-valg med hensyn til front-end-teknologien.
Desværre var der på det tidspunkt ikke defineret en klar strategi for statsforvaltningen. Efterhånden som projektet udviklede sig, begyndte det at blive et problem, så teamet besluttede at migrere al den logik relateret til statsstyring til en klasse, der præsenterede sig selv som en Singleton. Det ville hjælpe med al den statsrelaterede opbevaring og begivenheder. Denne løsning var fin på kort sigt, men til sidst ville den vokse ud af hans anvendelighed, og en plan blev sat i gang for at finde et bedre alternativ. Det kom i form af Redux, hjulpet af introduktionen af Redux værktøjssæt, tidligere kendt som Redux Starter Kit.
Redux er en tilstandsbeholder til JavaScript-applikationer, der giver dig mulighed for at omgå den naturlige ensrettede React dataflow. Dette er muligt, da det har en kilde til sandhed, som du kan konsultere i hele din applikation uden at skulle bore ned som en prop til andre komponenter. Det giver dig dog også mulighed for at ændre ved hjælp af foruddefinerede handlinger, samtidig med at du holder en historie med sådanne handlinger og mutationer, der kan konsulteres under test.
Da Facebook præsenterede React for verden, var det allerede tydeligt for dem, hvordan rekvisitter kunne blive en stor hindring, når de nåede et vist niveau af kompleksitet. For at afbøde dette problem introducerede de et koncept sammen med React kaldet Flux, som beskriver, hvordan en butik skal fungere sammen med React. Redux, som vi ved i dag, stammer kun fra et bevis på konceptet hacket af Dan Abramov, mens han pillede med Flux-principper for React Europe.
Redux bruges i store applikationer hvor en interaktion med en komponent kan udbrede ændringer til hele siden. For at lette denne form for kommunikation mellem komponenter, i stedet for at skulle oprette tilbagekald på det øverste niveau af applikationen, kan du bare konsultere butikken. I mit nuværende projekt giver Redux mening, fordi applikationen var eskaleret til et punkt, hvor rekvisitter relateret til dens tilstand blev sendt ned gennem flere lag af komponenter, hvilket igen gjorde koden svær at læse og endnu sværere at debugge.
Redux lignede en gave da vi begyndte at migrere gammel kode til denne nye funktion. Det gjorde kode ser glattere ud, det var ekstremt intuitiv at forstå og reducerede drastisk antallet af rekvisitter, der flyder rundt i applikationen. Men det var ikke perfekt. Selve arten af reduktionsmidler udgør et problem, når du omfatter hentning af information i dem, og det er noget, Redux-samfundet har tacklet i meget lang tid.
Reduktorer er i teorien rene funktioner ifølge dokumentationen sig selv.
Med de samme argumenter skal den beregne den næste tilstand og returnere den. Ingen overraskelser. Ingen bivirkninger. Ingen API-opkald. Ingen mutationer. Bare en beregning.
Så, hvor skal du anvende async-opkald i Redux?
Handlingerne skal være det umiddelbare svar, men den grundlæggende implementering af handlinger er intet andet end et almindeligt JavaScript-objekt, du bruger til at videregive oplysninger til din butik. Af denne grund kom samfundet med flere mellemvarer, der i stedet pakker al logikken ind i funktioner, som efterligner butikens naturlige opførsel.
Som med alt andet inden for programmering, der er ikke en løsning, der passer til alle. Så du bør bestemt undersøge, hvilken middleware der passer bedst til dit problem. Den første løsning, der foreslås af dokumentationen, er Redux Thunk. Denne middleware giver dig mulighed for at oprette handlinger som mere end almindelige objekter. Disse nye handlinger kan sende andre handlinger, andre Thunks og også udføre async-operationer inde i dem. Men for nylig er andre mellemvarer begyndt at få trækkraft, som Redux Saga og Redux-observerbar har forskellige brugssager, men de deler alle én ting, som er et meget aktivt lager og et blomstrende samfund bag dem.
Ud af alle de populære løsninger på dette problem, Redux Thunk er den nemmeste at forstå. Det er også ret tilgængeligt i tekniske termer, og på dette tidspunkt er det den foreslåede måde at nærme sig denne situation i henhold til Redux-dokumentationen.
Vi starter her:
Dette giver dig en frisk ny app, der bruger React med alle de Redux-moduler, vi havde brug for til at udføre denne korte tutorial. Vi vil også arbejde med WoofBot API-tjeneste.
Den første ting at gøre er at oprette et hundeskive, hvor du gemmer alle de oplysninger, der er relateret til dit hunde-API-svar.
Vi har vores handlinger:
og selektorer:
Hvordan ville du normalt implementere dette frem og tilbage med API'en og butikken? Jeg ville passe det hele ind i en Brug Effect krog, svarende til denne:
Hvad laver vi her?
Alternativt kan vi modtage en fejl fra API'en, som stopper flowet i trin 4 og indstiller indlæsningstilstanden til Fejl.
Dette fungerer, og det er ok. Men det har også flere ulemper. Hovedsageligt lægger det for meget logik i komponenten. Det kan ikke genbruges, og hvis du vil have adgang til disse oplysninger et andet sted, skal du altid sørge for, at denne komponent indlæses først.
Nu med Thunks:
Komponentlogikken ser sådan ud:
Vi er nødt til at oprette en ny FetchBreeds handling, der ligner meget den logik, vi tidligere havde i komponenten:
Denne enkle ændring af placering i koden løser de fleste af de problemer, vi havde tidligere. Vi har abstraheret kode fra komponenten, og vi har gjort dette specifikke stykke logik genanvendeligt gennem hele kodebasen. Disse oplysninger er ikke bundet til montering af komponenten længere, så nu kan du udstede en ny FetchBreeds handling, og dataene vil blive indlæst.
Dette gør os også i stand til at kæde Thunks i tilfælde af brug for mere kompliceret logik i vores handlinger. Vi kan også få adgang til staten direkte i stedet for at have brug for vælgere. Du vil dog stadig bruge vælgere til at sikre, at eventuelle ændringer i Redux ikke påvirker dine Thunks.
Afhænger af situationen. På samme måde kan du ikke bruge en ske til alt, løsningen skal vælges ud fra problemet og ikke omvendt.
I de seneste problemer, jeg har stået over for, var Thunks mere end nok til at tilfredsstille alle mine edge-sager. Men måske i dit tilfælde har du brug for en mere specifik løsning.
Lav din forskning, hold dig opdateret, og du vil altid have det bedste værktøj på din side.
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Din daglige webudvikler, der kan lide at gemme sig i backend. Javascript og Ruby er min marmelade. Jeg fumler stadig med Docker, og mine bygninger går i stykker ret ofte.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
