Så du har precis avslutat del 1 och är hungrig efter mer? Då har du kommit till rätt ställe! Utan vidare, låt oss fortsätta vår resa. 😎
- Strukturering av mappar
Mappstruktur i alla projekt är mycket viktigt för underhållbarhet, och om du använder redux måste du verkligen tänka på korrekt organisation så att du enkelt kan komma åt alla moduler i din kod senare. Det finns två grundläggande tillvägagångssätt för att strukturera mappar i React Native. Den första är funktion-först-strategi , där mappar namnges efter funktionen hos deras filer, till exempel behållare, komponenter, åtgärder, Reducerare. Det låter enkelt, men skalar fruktansvärt och det är en enda röra att inkludera alla filer som krävs för en enda skärm. Den andra är funktion-först-strategi, där varje mapp innehåller allt om en specifik modul i appen, så i det här fallet skulle du ha mappar som profil, Logga in, foder, meddelanden och så vidare. Detta skalar mycket bättre men gör ingen tydlig åtskillnad mellan ditt användargränssnitt och redux.
Den bästa lösningen är att alltid försöka separera tillståndshanteringsfiler från UI-komponenter. Så du kan använda "Bästa av båda världar" -metoden, som är Ankor filarkitektur. I det här tillvägagångssättet är alla UI-filer isolerade i views mapp, vars inre arkitektur är funktion-förstoch alla statsrelaterade filer förvaras i redux mapp, med en specifik uppsättning krav. Att beskriva Ducks modulära mönster i detalj ligger utanför ramen för den här artikeln, men om du skapar ett nytt projekt kan du kolla upp det och se hur du kan implementera det i din app. - Använd package.json för att undvika relativa sökvägarIom du är en React Native-utvecklare har du förmodligen något liknande någonstans i din kod:
import MyList from '../../../../../views/components/MyList'.
Det är inte coolt, det är tröttsamt och inte lätt att underhålla.
Men det finns ett sätt att lösa det! Om du vill undvika att skriva alla dessa ../../../och importera direkt från komponenter är allt du behöver göra att skapa en paket.json filen inuti komponenter mapp, med följande innehåll: { "name": "components" }.
Nu är mappen omvandlad till en modul och du kan importera på det här sättet: import MyList from 'components/MyList'. Tänk dock på att om du gör detta inaktiverar importfunktionen för autokomplettering i Visual Studio Code, så du kanske bara vill använda den i specifika fall, t.ex. för att importera statiska tillgångar (bilder). - Använd debounce om du skickar API-anrop ofta
Om du skickar en API-begäran för varje tangenttryckning (t.ex. hämtar sökförslag medan användaren skriver något i sökfältet) kan antalet begäranden bli överväldigande om användaren skriver snabbt. Du kan använda lodash funktion _.debounce(onChangeText, 500) om du vill ställa in en hastighetsgräns för att skicka begäranden. - Implementera laddningsindikatorer medan du väntar på API-svar
Det här är något som är väldigt enkelt att implementera, men det kommer att förbättra känslan av din app drastiskt och få den att se mer responsiv och professionell ut för användarna. - Implementera tomma platshållare när det inte finns några data
Tomma platshållare, oavsett om det är bilder eller enkla etiketter som "Du har inga meddelanden", gör att appen ser snygg ut även i de fall där det inte finns några data. Första intrycket är oerhört viktigt, och dina nya användare kommer sannolikt att stöta på fall där det inte finns några data. Låt dem inte stirra in i en tom skärm. - Bli bekväm med grunderna i native-kod på båda plattformarna
Du behöver inte vara en native iOS/Android-utvecklare för att vara en React Native-utvecklare, men du bör åtminstone veta hur man använder iOS Pods, Info.plist och hur man manuellt länkar bibliotek. Detsamma gäller för Android och dess Gradle-process och AndroidManifest-konfiguration. - Undvik tunga beräkningar i render()
Din render() funktionen måste vara så enkel som möjligt, eftersom det är den som anropas mest under hela livscykeln. Så håll den ren från alla tunga beräkningar för att öka prestandan i din app. Om du vill snabba upp en specifik komponent är en av de första sakerna du bör göra att räkna dina renderingar och se om det finns för många av dem. - Rena komponenter
Eftersom ett av de största prestandaproblemen i React Native är för många onödiga render() anrop kan du utöka PureComponentvars syfte är att minska antalet sådana anrop. Till exempel kommer en funktionell komponent att renderas varje gång dess överordnade komponent renderas, men en ren komponent kommer inte att göra det, eftersom den implementerar en livscykelmetodshouldComponentUpdate för att kontrollera om en rendering verkligen krävs (den kontrollerar faktiskt om det finns ändringar i tillstånd eller props). Du måste dock vara försiktig och förstå hur det fungerar, eftersom du kan stöta på falska negativ om din komponent innehåller komplexa datastrukturer vars ändringar inte kommer att upptäckas. - Rensa upp parametrar som du inte längre använder i komponenter
Om din komponent har genomgått en omfattande refaktorisering är chansen stor att vissa av de props som den tar emot inte längre används. Rensa upp dem regelbundet för att få en renare kod och en bättre allmän uppfattning om dataflödet i din applikation. - Organisera dina konstanter
Om du har Konfigurationsvariabler som du använder på många ställen i din app, t.ex. navigeringsfältets höjd, sidomenyns bredd, sidstorlek för API-anrop, enumer och så vidare, ska du spara dem som namngivna konstanter i en särskild fil så att du alltid kan hitta och redigera dem enkelt.
Detsamma gäller för färger. I stället för att hårdkoda HEX-värden över hela projektet kan du samla alla dina färger i en fil så att du alltid kan hålla reda på varje värde. Och ja, du bör skapa konstanter även för svart och vit färger, eftersom designkraven kan ändras senare (på grund av varumärkesbyte, projektägaren har bytts ut etc.), och du kan behöva ändra alla svarta färger i ditt projekt till en annan nyans av svart, eller en helt annan färg. Se till att revidera och städa upp den här filen regelbundet så att den inte blir belamrad med gamla, oanvända värden. Att namnge dina färger på rätt sätt är också viktigt. Om huvudfärgen i din app är blå ska du inte namnge konstanten COLOR_BLUE för om det ändras till rött senare måste du byta namn på varje enskild instans till COLOR_RED. Använd COLOR_BASE istället.
Du bör också behålla alla dina meddelandesträngar i en lokaliseringsfil så att du enkelt kan översätta dem när behovet uppstår. Även om du inte behöver översätta din app inom en snar framtid är det ändå bra att ha en lista med alla meddelanden på ett och samma ställe. - Kontrollera hela tiden hur appen ser ut på olika plattformar och enheter
Om du hela tiden är medveten om hur din app ser ut på olika skärmdimensioner (större telefoner, mindre telefoner, surfplattor) kommer du att spara mycket tid och arbete i det långa loppet. Även om du bara utvecklar för en plattform bör du dessutom ha den andra i åtanke. Om du till exempel använder ActionSheetIOS fungerar det inte på Android, så du måste antingen skriva om den koden eller skapa ett Android-specifikt alternativ senare. - Välj variabel namngivningsstil och håll dig till den
Du gillar camelCase? Jättebra. Eller så är du mer av en underscore_case person? Det är också jättebra. Vi ska inte go diskutera vilken metod som är bäst, eftersom båda har sina för- och nackdelar. Det viktiga är att välja en och hålla sig till den, och inte blanda ihop dem. Var konsekvent. - Öka det berörbara området med hitSlop
Om du har en liten knapp som är svår att trycka på kan du öka padding-värdena för att öka den beröringsbara ytan, men du kan också använda en egenskap hitSlop för att uppnå samma syfte. - Hantera problem med tangentbordet
Ett tangentbord är varje mobilutvecklares nemesis. Har du någonsin stött på ett problem där du får upp en lista med klickbara rader, men eftersom ditt tangentbord är öppet måste du trycka två gånger: första gången för att stänga tangentbordet och andra gången för att raden ska reagera och öppna en skärm? React Natives <ScrollView> och<FlatList> båda har en användbar egenskap som kallas tangentbordSkaPersistTryckningar. Om du ställer in värdet på "alltid" förhindras detta otrevliga beteende.
Ett annat problem som ofta uppstår är att tangentbordet överlappar de textinmatningsfält som du ska skriva i. Lyckligtvis finns det bibliotek där ute som t.ex. react-native-tangentbord-undvikande-skrollvy, som förhindrar att denna olägenhet inträffar. - Använd alltid både lokal validering och servervalidering
Visst finns det vissa saker som bara servern kan validera, till exempel validering av om den angivna e-postadressen finns i databasen. Men du bör alltid implementera så mycket klientvalidering som möjligt, t.ex. regex för e-postformat, minsta/maximala antal tecken och validering av tomma fält. - Använd lämpliga datastrukturer
Utgå inte från att alla datasamlingar måste placeras i en array. Kanske är det bättre med en nyckel-värde-datastruktur som en hashmap. Om dina ID:n är siffror måste de lagras i en datatyp för siffror, t.ex. integer, även om servern returnerar dem som strängar i JSON-svaret. - Undvik att ställa in bredd och höjd för containerkomponenter
Om din komponents underordnade komponenter redan har inställda dimensioner, dubbelkolla om det verkligen är nödvändigt att ställa in dimensioner för containerkomponenten också. Ibland kan det vara användbart, men oftast är det bättre att låta containerkomponenterna ändra storlek själva baserat på dimensionerna hos deras barn. - Hårdkoda data i reducerare om API-anropet inte är klart
Om du väntar på att ett specifikt API-anrop ska implementeras på backend kan du hårdkoda det överenskomna serversvaret i dina reducerare. På så sätt hindras du inte från att utveckla en ny funktion och när API-anropet är klart kommer integrationen att vara sömlös. - Var medveten om din kods komplexitet
Du bör åtminstone delvis ha koll på din kods beräkningskomplexitet. Ibland lägger en komponent mer tid på att bearbeta data den tagit emot än på att vänta på ett svar från servern. Du kan använda Visual Studio-tillägg somCodemetricsför att hålla koll på kodens komplexitet i varje metod. Det betyder inte att du behöver gå igenom hela din kodbas med ” go ” för att försöka optimera allt. När allt kommer omkring kan prestandan hos en släppt app på en riktig enhet skilja sig avsevärt från debug-versionen på din simulator/emulator, så fall inte i fällan med för tidig optimering (”För tidig optimering är roten till allt ont” ~ Donald Knuth). - Var medveten om skillnaden mellan att navigera och att trycka på skärmar
Oavsett vilket navigeringsbibliotek du väljer att använda för din app är reglerna desamma. Vissa åtgärder kräver att en ny skärm läggs till i applikationsstacken, medan andra kräver att du går till en skärm som du har laddat tidigare. Push-åtgärden lägger till en rutt ovanpå stacken och navigerar framåt till den. Åtgärden Navigate hoppar tillbaka till tidigare i stacken om en komponent redan är monterad där. Push lägger alltid till på toppen, så att en komponent kan monteras flera gånger. Detta är viktigt för tillbaka och för de data som du vill presentera. Vill du t.ex. tillåta att en profil öppnas från en annan? Du behöver en push-åtgärd, eftersom du i princip laddar samma komponent två gånger, med olika data, och du vill kunna återgå till den tidigare profilen med bakåtknappen. - Använd aldrig någonsin Find/Replace-funktionen för refaktorisering
Det kan verka som en snabbare lösning om du snabbt behöver ändra en massa saker i ditt projekt, men det finns alldeles för många fallgropar du kan (och lita på mig, du kommer att) hamna i. Så bry dig inte ens om det, och gör saker på det gammaldags sättet, eller refaktorera med hjälp av refaktoriseringsverktygen som tillhandahålls av din IDE. - Tänk på Human Interface Guidelines för Apple och Material Design Guidelines för Android
Detaljer i gränssnittsdesignen som teckenstorlek, textavstånd, bildupplösningar, komponentorganisation och knappdimensioner kanske inte låter så viktiga, men de gör hela skillnaden för dina användare. Till och med beslut som om "OK"- eller "Avbryt"-knappen ska sitta på vänster eller höger sida av skärmen är viktiga. Så se till att undersöka vad som är bra och mindre bra för iOS och Android för att kunna ge dina användare en fantastisk UX. - Var mycket försiktig med Copy/Paste-operationer
Du kanske vill kopiera en komponent, funktion eller någon annan kod och modifiera den. Det är här många oväntade fel inträffar eftersom det kan vara mycket svårt att märka en enda egenskap eller ett värde som du har glömt att ändra. Så var alltid på tårna när du gör någon typ av kopiera/klistra in. - Transparens i färg HEX-koder
Låt oss säga att du definierar färger i din app med deras hexadecimala rrggbb värden. I det här fallet skulle du skriva ren svart färg som #000000, ren vit som #FFFFFF och rent grön som #00FF00. Men vad händer om du vill lägga till ett transparensvärde till färgen? Enkelt, använd bara rrggbbaa notation, där de två sista siffrorna representerar procentandelen av den önskade färgen.
Så vad skulle vara det korrekta HEX-värdet för svart färg med 50% opacitet? Det första jag kommer att tänka på är #00000050. Men detta är fel! Eftersom värdena för opacitet sträcker sig från 0 till 255, skulle det korrekta värdet för 50% vara 127, vilket motsvarar ett hexadecimalt värde av 7F. Därför skulle det korrekta svaret i detta fall vara #0000007F. För en fullständig konverteringstabell för procent till hex, kolla in denna länk. - Lås beroenden
Om din paket.json filen har ett beroende som ser ut som
"some-cool-library": "^0.4.2"kan det vara bra att ta bort ^ för att låsa beroendet till den specifika versionen. Detta kommer att säkerställa att du inte importerar ändringar från de nya versionerna av biblioteket till ditt projekt.
Det var allt! Jag hoppas att du tyckte att den här lilla guiden var användbar.
Låt mig veta om du har andra React Native eller mobilutvecklingstips i kommentarerna! 😃
