Det är ingen överraskning för någon att JavaScript finns överallt.
Här på Imaginärt moln, de flesta av de projekt vi är involverade i, använder det som huvudspråk. Mitt sista projekt var en ganska stor applikation som involverade de vanliga syndarna i JavaScript ekosystem. Vi använde en React front-end och en Node.js back-end stack.
När vi behövde definiera en stack för detta projekt, på grund av dess natur att involvera mycket visuell presentation och 3D-modellering, presenterade React sig själv som ett no brainer-val, när det gäller front-end-tekniken.
Tyvärr var vid den tiden inte en tydlig strategi för statlig förvaltning definierad. När projektet utvecklades började det bli ett problem, så teamet beslutade att migrera all logik relaterad till statshantering till en klass som presenterade sig som en Singleton. Det skulle hjälpa till med all statsrelaterad lagring och händelser. Denna lösning var bra på kort sikt, men så småningom skulle den växa ur hans användbarhet och en plan sattes i gång för att hitta ett bättre alternativ. Det kom i form av Redux, hjälpt av införandet av Redux Verktygssats, tidigare känd som Redux Starter Kit.
Redux är en tillståndsbehållare för JavaScript-applikationer som låter dig kringgå det naturliga enkelriktade dataflödet i React. Detta är möjligt eftersom det har en källa till sanning som du kan konsultera i hela din applikation, utan att behöva borra nedströms som en rekvisita till andra komponenter. Men det låter dig också ändra med fördefinierade åtgärder, samtidigt som du behåller en historik över sådana åtgärder och mutationer, som kan konsulteras under testning.
När Facebook presenterade React för världen var det redan uppenbart för dem hur rekvisita kunde bli ett stort hinder när de nådde en viss nivå av komplexitet. För att mildra detta problem introducerade de ett koncept vid sidan av React som heter Flux, som beskriver hur en butik ska fungera tillsammans med React. Redux, som vi vet idag, härrör från bara ett bevis på konceptet hackat av Dan Abramov, medan han pysslade med Flux-principer för React Europe.
Redux används i storskaliga applikationer där en interaktion med en komponent kan sprida ändringar till hela sidan. För att underlätta denna typ av kommunikation mellan komponenter, istället för att behöva skapa återuppringningar på applikationens översta nivå, kan du bara konsultera butiken. I mitt nuvarande projekt är Redux vettigt, eftersom applikationen hade eskalerat till en punkt där rekvisita relaterade till dess tillstånd skickades ner genom flera lager av komponenter, vilket i sin tur gjorde koden svår att läsa och ännu svårare att felsöka.
Redux såg ut som en gudagåva när vi började migrera gammal kod till den här nya funktionen. Det gjorde koden ser snyggare ut, det var extremt intuitivt att förstå och minskade drastiskt antalet rekvisita som flyter runt applikationen. Men det var inte perfekt. Reduktörernas natur utgör ett problem när du omfattar hämtning av information i dem, och det är något Redux community har tagit itu med under mycket lång tid.
Reduktorer är i teorin rena funktioner, enligt dokumentationen sig.
Med tanke på samma argument bör det beräkna nästa tillstånd och returnera det. Inga överraskningar. Inga biverkningar. Inga API-anrop. Inga mutationer. Bara en beräkning.
Så, var ska du tillämpa asynkroniska samtal i Redux?
Åtgärderna bör vara det omedelbara svaret, men den grundläggande implementeringen av åtgärder är inget annat än ett vanligt JavaScript-objekt som du använder för att skicka information till din butik. Av denna anledning kom samhället med flera mellanvaror som istället slår in all logik i funktioner, som efterliknar butikens naturliga beteende.
Som med allt inom programmering, det finns ingen lösning som passar alla. Så du bör definitivt undersöka vilken middleware som passar ditt problem bäst. Den första lösningen som föreslås av dokumentationen är Redux Thunk. Denna mellanprogramvara låter dig skapa åtgärder som mer än vanliga objekt. Dessa nya åtgärder kan skicka andra åtgärder, andra Thunks och även utföra asynkroniska operationer inuti dem. Men nyligen har andra mellanprodukter börjat få dragkraft, som Redux Saga och Redux-observerbar har olika användningsfall men de delar alla en sak, vilket är ett mycket aktivt arkiv och blomstrande samhälle bakom dem.
Av alla populära lösningar på denna fråga, Redux Thunk Det är lättast att förstå. Det är också ganska tillgängligt i tekniska termer och för närvarande är det det föreslagna sättet att närma sig denna situation enligt Redux dokumentation.
Vi börjar här:
Detta ger dig en ny ny app som använder React med alla Redux-moduler vi behövde för att göra denna korta handledning. Vi kommer också att arbeta med WoofBot API-tjänst.
Det första du ska göra är att ställa in en hundskiva, där du kommer att behålla all information relaterad till ditt hunds API-svar.
Vi har våra handlingar:
och väljare:
Hur skulle du normalt implementera detta fram och tillbaka med API och butiken? Jag skulle passa in allt i en Använd effektkrok, liknande den här:
Vad gör vi här?
Alternativt kan vi få ett fel från API som stoppar flödet i steg 4 och ställer in laddningstillståndet till fel.
Det här fungerar, och det är ok. Men det har också flera nackdelar. Huvudsakligen lägger det för mycket logik i komponenten. Det är inte återanvändbart, och om du vill komma åt denna information någon annanstans måste du alltid se till att den här komponenten laddas först.
Nu med Thunks:
Komponentlogiken ser ut så här:
Vi måste skapa en ny FetchBreeds åtgärd som ser mycket ut som den logik vi tidigare hade i komponenten:
Denna enkla ändring av plats i koden fixar de flesta av de problem vi hade tidigare. Vi har abstraherat kod från komponenten och vi har gjort denna specifika bit av logik återanvändbar genom hela kodbasen. Denna information är inte bunden till montering av komponenten längre, så nu kan du utfärda en ny FetchBreeds åtgärd och data kommer att laddas.
Detta gör det också möjligt för oss att kedja Thunks om det behövs mer komplicerad logik i våra handlingar. Vi kan också komma åt staten direkt, istället för att behöva väljare. Du vill dock fortfarande använda väljare för att se till att eventuella ändringar i Redux inte påverkar dina Thunks.
Beror på situationen. På samma sätt kan du inte använda en sked för allt, lösningen måste väljas utifrån problemet och inte tvärtom.
I de senaste frågorna jag har mött var Thunks mer än tillräckligt för att tillfredsställa alla mina edge-fall. Men kanske i ditt fall behöver du en mer specifik lösning.
Gör din forskning, håll dig uppdaterad så har du alltid det bästa verktyget på din sida.
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Din dagliga webbutvecklare som gillar att gömma sig i backend. Javascript och Ruby är min sylt. Jag fumlar fortfarande med Docker och mina byggnader går sönder ganska ofta.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
