Letar du efter något som hjälper dig att skriva mobilapplikationer i React Native som beter sig konsekvent, körs i olika miljöer och testar enkelt? Det finns en lösning, och du har precis hittat den!
Du har säkert stött på det faktum att när din applikation blir större och mer komplex är det svårt att hantera tillstånd och skicka data från en komponent till en annan komponent (eller underordnade komponenter). Det är exakt där redux kan hjälpa dig: det ger global åtkomst till tillstånd eller data, som kan användas i vilken komponent som helst utan att vara beroende av andra komponenter.
Artikeln är en nybörjares omfattande om hur man använder redux och redux toolkit i en React Native-applikation. Den här guiden förutsätter att du känner till grunderna i React Native men, om detta också är nytt för dig, vi har täckt dig med vår Handledning för React Native. Vi använder också en Android-emulator i den här handledningen, något som låter dig simulera en Android-enhet på din dator så att du kan testa din applikation på en mängd olika enheter och Android API-nivåer utan att behöva ha varje fysisk enhet. Lägg märke till att denna emulator ger nästan alla funktioner hos en riktig Android-enhet.
Slutligen, för att hjälpa dig att lära dig grunderna i redux, tillhandahåller vi, längs vägen, kodexempel på en enkel motapplikation. Det kommer att se ut så här:
Här är koden för vår SimpleCounter-komponent:
Just nu är denna kod statisk, och vi har inte deklarerat något tillstånd inuti komponenten. Följ gärna med kodexemplen när vi integrerar redux i vår react native-app. Vår React Native-handledning (länk ovan) visar dig hur du ställer in en React Native-miljö, efter det, se till att du installerar redux- och react-redux-biblioteken. För att göra det använder du bara kommandot:
Om du använder npm 5.0.0 eller överlägsen skriver du detta istället:
Redux är ett javascript-bibliotek gjort för att hjälpa dig hantera tillståndet för din applikation. Det gör det genom att förse utvecklaren med en centraliserad plats som kallas butiken, där staten sparas och modifieras genom åtgärder och reducerare. Denna centraliserade plats gör att du kan dela tillståndet mellan flera skärmar och veta exakt var och hur tillståndet ändras. Detta är särskilt användbart i växande applikationer som är för stora för att utvecklarna ska ha full kunskap om dataflödena och följaktligen bli buggprome.
Som nämnts ovan använder redux en kombination av åtgärder, reducerare och butiken för att hantera applikationstillståndet. För att förstå och lära dig redux måste du veta hur dessa abstraktioner fungerar. Låt oss börja!
Mycket lätt är applikationstillståndet all information som applikationen använder och/eller modifierar. Att ha ett centraliserat tillstånd och ett förutsägbart sätt att ändra det kan göra det möjligt för applikationer att vara sammanhängande med informationen som de visar för användarna. Detta är särskilt användbart för stora enkelsidiga applikationer.
Åtgärder och reducerare ändrar tillsammans tillståndet. Exakt, åtgärder avgör vad som ändras och var. Reduktorer anger hur det ändras. Genom att analysera layouten i början av blogginlägget behöver vi tre åtgärder: INCREMENT, DECREMENT och CHANGE_BY_AMOUNT. Åtgärder är objekt med en typ och ett nyttolastattribut. Typen är åtgärdens identifierare, och nyttolasten är all information som reduceraren behöver för att ändra tillståndet. De två första åtgärderna kommer bara att minska eller öka räknemängden med 1, så vi behöver bara definiera två objekt med attributtypen, och reduceraren hanterar resten. Den tredje åtgärden måste ha en nyttolast för att ange hur mycket vi vill öka eller minska räknaren. Förklara dina åtgärder i en separat fil som heter Åtgärder:
Som du kan se är det ganska enkelt. Därefter definierar vi det ursprungliga tillståndet. Detta görs i en annan fil tillsammans med reduceraren:
Vi ställer in initialtillståndet för att ha ett objekt som heter räknare med attributbeloppet, med början på 0. Du kan också se att det ursprungliga tillståndet är en konstant och inte en variabel, vilket verkar inte vara meningsfullt, men vi kommer att förklara det för dig senare. Därefter bygger vi reduceraren, som är en funktion som tar emot det aktuella tillståndet och åtgärden - som argument - för att producera applikationens nya tillstånd. Här är det:
Vi får inte mutera tillståndet i reduceraren. Varför? Faktum är att reduceraren inte bör modifiera tillståndsobjektet direkt. Istället bör det skapa ett nytt objekt, vilket kommer att vara det nya tillståndet. Reacts renderingsmotor jämför det föregående tillståndsobjektet med det senaste tillståndsobjektet.
Om du ändrar tillståndet direkt vet React inte vad som har förändrats, och det kommer att ha en bristfällig uppfattning om applikationstillståndet. Du kan börja läsa om detta här. Det är därför vi i början förklarade initialtillståndet som en konstant och inte som en variabel, eftersom vi låtsas att det ursprungliga tillståndsobjektet aldrig skulle ändras.
Nästa steg är att skapa butiken. Butiken är objektet där staten sparas. Det är vanligt att skapa butiken och exportera den i en separat fil. Kontrollera det nedan:
Vi skapar butiken med metoden createStore () från redux, som tar emot reduceringsfunktionen som definierats tidigare som argument. Med butiken kan vi åberopa åtgärder med avsändningsmetoden (kommer att visas senare i den här guiden) för att ändra tillståndet.
Nu gör vi butiken tillgänglig genom att skicka den till leverantörskomponenten som uppslukar vår SimpleCounter-komponent. Vad Provider-komponenten gör är att ge åtkomst till butiken i SimpleCounter-komponenten och alla komponenter inuti den.
Provider-komponenten importeras från react-redux-biblioteket, som är det officiella bindningsbiblioteket för react/react native och redux.Se nedan hur du gör det:
Därefter vill vi ansluta våra komponenter till redux-butiken. Vi kan göra detta genom att använda anslutningsmetoden från react-redux-biblioteket i vår SimpleCounter-komponentfil, så här:
Vi måste skicka två argument till anslutningsmetoden: komponenten vi vill ansluta (SimpleCounter) och en funktion som mappar applikationstillståndet till våra komponentrekvisita.
Observera att vi bara har tillgång till statsobjektet i MapStateToProps-funktionen eftersom vi uppslukade SimpleCounter-komponenten med Provider-komponenten.
Connect-metoden slår samman objektet som returneras från mapStateToProps med props för komponenten SimpleCounter för att komma åt värdet state.counter.amount via this.props.amount.
Sändningsmetoden blir också tillgänglig via rekvisita, och vi kan nu importera våra åtgärder och skicka dem inuti SimpleCounter-komponenten. Här är den uppdaterade koden för SimpleCounter-komponenten:
Så nu har vi en centraliserad butik där tillståndet sparas och modifieras på ett förutsägbart sätt genom åtgärder och reducerare, men du kanske har märkt att räknarvärdet återgår till noll varje gång du uppdaterar eller avslutar appen, detta beror på att just nu inte tillståndet kvarstår och varje gång du öppnar applikationen definierar reduceraren räknarvärdet till noll (det ursprungliga tillståndet).
Tillståndsbeständighet är viktigt om du behöver behålla viss information även när användaren stänger programmet, till exempel inloggningstoken eller vissa konfigurationsinställningar. Du kan uppnå tillståndsbeständighet i en React Native-app genom att använda biblioteket redux-persistent.
Redux persistent sparar redux-butiken i en lokal beständig lagring och hämtar den varje gång appen öppnas igen eller uppdateras. Vi använder en Android-emulator, men redux-persistent fungerar också med IOS. Låt oss börja med att installera redux persistent:
Därefter ändrar du filen Store.js, så här:
Importera först både PersistStore- och PersistReducer-metoder från redux-persist-biblioteket. Skicka reduceraren till PersistReducer-metoden längs med PersistConfig-objektet för att skapa en PersistedReducer.
I PersistConfig-objektet deklarera att du ska använda AsyncStorage för att behålla redux-butiken som är en okrypterad nyckelvärdelagring från React Native.
Slutligen, ring PersistStore-metoden för att säkerställa att vår butik kvarstår. Om du har ett större projekt kanske du inte behöver behålla hela tillståndet, i så fall kan du använda en ”Whitelist” och ”Blacklist” -metod i PersistConfig-objektet för att välja vilka reducerare du vill behålla, klicka här om du vill veta mer.
Slutligen importerar du PersistedStore från Store.js i filen App.js och slukar SimpleCounter med PersistGate-komponenten för att se till att appens användargränssnitt inte återges förrän det kvarvarande tillståndet hämtas och sparas i redux-butiken.
Vi måste nämna Redux toolkit, ett bibliotek skrivet av redux-utvecklarna för att skapa effektivare redux-logik. Att använda bibliotekets funktioner kommer att resultera i att din kod blir mer kompakt och enklare att läsa. Här är en introduktion till några av dessa funktioner:
Redux toolkit introducerade oss med ett nytt sätt att skapa en åtgärd. Det fungerar så här:
Metoden createAction tar emot åtgärdstypen som ett argument och returnerar en funktion för att skapa åtgärder. Vi kan sedan anropa den här funktionen och skicka nyttolasten som ett argument för att skapa åtgärdsobjektet. Du kan också komma åt åtgärdstypen med metoden toString (), till exempel IncrementAction.toString (). Den här metoden gör det så att vi inte längre behöver deklarera åtgärdstyperna som konstanter som minskar pannplatskoden avsevärt.
Detta är en annan metod för redux-verktygssatsen som syftar till att förenkla vår kod. Metoden tillåter oss att skriva reducerare med uppslagstabellnotationen, vilket gör att vi kan skriva en mycket renare kod. Objekten som returneras från metoden createAction () kan användas direkt som tabellnycklar. Efter den tidigare reduceringslogiken har vi:
Utöver detta använder createReducer () också Immer för att skriva reducerare med enklare muterande logik. Immer översätter alla muterande operationer till motsvarande kopieringsoperationer. Så nu kan vi skriva vår reducerare så här:
Mycket enklare tycker du inte?
Funktionen configureRestore () omsluter metoden createStore () och skapar butiken som ställer in vissa standardkonfigurationer. Metoden tar också emot ett konfigurationsobjekt istället för en grupp funktioner, så när du använder det måste du skicka reduceraren inuti ett objekt som är associerat med reduceringsattributet. Så här:
Butikskonfiguration är en fråga som vi inte inkluderade i det här blogginlägget, men vi kände att det fortfarande var viktigt att nämna så, om du vill, känn dig fri att utforska det själv. En sak till, om du vill integrera redux-persistent och redux-toolkit i samma projekt kanske du har stött på felet ”Ett icke-serialiserbart värde upptäcktes i en åtgärd” beror det på att redux-toolkits configuRestore () innehåller en serialiserbar kontroll av åtgärder och redux-persistent måste skicka en funktion inuti dem. Ett sätt du kan lösa detta är att importera getDefaultMiddleware från redux-toolkit och inaktivera den serialiserbara kontrollen av redux-persistent åtgärdstyper. Så här:
Du kan hitta diskussionen och lösningen på detta problem i detta forum.
Där är det. Resultatet ska vara en enkel men funktionell räknarapp. Vi hoppas att du lärde dig hur redux abstraktioner fungerar tillsammans och bekanta dig med de dataflöden som de skapar, så det blir lättare för dig att börja tillämpa redux på din app. Dessutom är redux ett oberoende bibliotek, så logiken du lärde dig här skulle vara densamma om du ville integrera redux i en webbapplikation som använder react. Önskar dig lycka till med programmering!
Datavetenskapsstudent och ImaginaryCloud deltidsarbetare. Ivrig efter att lära sig ny teknik och teknik. Tennis- och pianospelare.
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)
