Beste fremgangsmåter for å lage React Native apps - Del 1

Bilde 1: Abstrakt bilde med React-logo

Hvis du er ny i React Native verden, er det noen fallgruver som du sannsynligvis vil unngå, mens du i noen andre tilfeller må ta valg på forhånd kanskje uten å vite hvor viktige de er.

Nedenfor har jeg samlet en liste over beste praksis fra min personlige erfaring, som jeg håper du vil finne nyttige :-)

Bruk Expo-Kit bare hvis du vet nøyaktig hva du gjør

Expo er en gratis og åpen kildekode-verktøyskjede for React Native. Det er sannsynligvis det beste settet der ute for React Native-apper, men det kommer med begrensninger.

Bruk Expo:

  • Hvis du vil ha en rask lekeplass og ikke bygge appens depot. Bare opprett en ny app med hjelpen til å opprette-reagere-native-app-pakken.
  • Hvis du har gjort utvidet undersøkelse av appen du skal bygge, og alle kravene kan dekkes fra Expos tilbudte løsninger.
  • Hvis du ikke har en Mac-datamaskin, og du absolutt vil bygge appen din også for iPhone. Det er det eneste alternativet for å bygge kjørbare IPAer.

Ikke bruk Expo:

  • Hvis du er ukjent med React Native, og du tror dette er "må" -veien å gå. Sjekk om det tilfredsstiller dine behov først.
  • Hvis du planlegger å bruke RN-pakker fra tredjepart som har tilpassede innbyggede moduler. Expo støtter ikke denne funksjonaliteten, og i så fall må du fjerne Expo-Kit. Etter min mening, hvis du skal ta ut noe sett, ikke bruk det i utgangspunktet. Det vil sannsynligvis gjøre ting vanskeligere enn om du ikke hadde brukt settet i det hele tatt.

Totalt sett synes jeg Expo er et flott verktøy, og jeg bruker Expo Snack for å dele RN-kodebiter. Men akkurat nå kan det være til hjelp bare for å bygge visse typer apper.

Slik strukturerer du applikasjonsmapper / filer

Strukturering av React Native-appen din er ikke forskjellig fra å strukturere React-appen din. Så hvis du er kjent med det, kan du følge din eksisterende logikk. Men hvis du ikke er det, kanskje du vil finne nyttig logikken som er foreslått nedenfor:

Bilde 2: Fil- / mappestruktur for React Native-appen
  • Legg til en mappe i roten som heter "app"
  • Lag mapper i appen:

eiendeler - Jeg bruker opptil 3 mapper her: skrifter, ikoner og bilder

komponenter - Det er her du plasserer alle delte React-komponenter. Vanligvis er disse komponentene de som vi kaller "dummy", som ikke har noen tilstandslogikk og lett kan gjenbrukes over hele appen.

visninger - Dette er applikasjonsskjermene våre, de som vi navigerer fra hverandre til. Dette er også React-komponenter, men det er de vi kaller containere, fordi de inneholder sin egen tilstand.

moduler - Det er brikker som ikke har noen tilsvarende visningsdel (JSX). Typiske eksempler på det er fargemodulen (inneholder alle appfargene) og verktøymodulen (inneholder nyttefunksjoner som blir brukt på nytt).

tjenester - Dette er funksjonene som pakker API-anropene.

i18n - Dette er oversettelsesstrengene for brukere av forskjellige språk og språk

Alle apper krever en slags konfigurasjon, så jeg lager vanligvis en fil som heter config.js og legger den der inne. Hvis konfigurasjonsfilen når mange linjer, kan vi deretter opprette en konfigurasjonsmappe og skille konfigurasjonen i filer.

Hvis du har et bibliotek for statlig leder, trenger du også mapper for strukturen. Når det gjelder Redux brukes to mapper til, en for handlinger og en annen for reduksjonsmaskiner. Hvis du ikke bruker en ekstern pakke og foretrekker å bruke React's Context API, oppretter du dine egne leverandører, som kan plasseres enten i modulmappen eller i en ny mappe kalt leverandører.

Velg et navigasjonsbibliotek etter dine behov helt fra begynnelsen

Dessverre har RN ikke gitt en solid løsning ennå eller til og med en erstatning for gammel Navigator-komponent, og vi fokuserer nå på samfunnsløsninger. Så hvis du skal til å starte et prosjekt, vil du vite hvilket navigasjonsbibliotek du skal bruke, og om det vil være det rette for deg.

Totalt sett er det to typer navigasjonsbiblioteker. JavaScript-navigatorene og de innfødte navigatørene. JavaScript-modulene er skrevet i JavaScript, mens de innfødte er skrevet som innfødte moduler på den respektive plattformen (Android, iOS) og er brokoblet til JavaScript-moduler for å bli påkalt i koden. De førstnevnte er mye lettere å konfigurere mens de sistnevnte er mye mer utøvende. Bruk tiden på å finne ut hvilke av dem du trenger, og velg deretter en av de mange der ute.

Spencer Carli har gjort en god jobb med å utdype de gjeldende navigasjonsvalgene i React Native world i denne artikkelen, som jeg foreslår at du vil lese. De dominerende alternativene er React Navigation som en JavaScript-løsning og React Native Navigation som en Native-løsning.

Bruk et CSS-in-JS-innpakningsbibliotek for enkelhets skyld

I React Native er CSS skrevet i JavaScript. Det er noe vi ikke har noe valg om. I stedet for å bruke StyleSheet.create metode og kode CSS som ren JavaScript, foretrekker jeg å bruke Styled Components-biblioteket. Stylede komponenter gjør at skriving av CSS føles intuitivt igjen og får JSX til å se mer semantisk ut.

Nylig skrev jeg en artikkel om hvorfor jeg foretrekker å bruke Styled Components i React Native-apper, slik at du kan ta en titt der for mer informasjon.

Bestem tidlig hvordan du vil at appen din skal skaleres på forskjellige enheter og skjermstørrelser

Sjansen er at du utvikler en app for mer enn én enhetsstørrelse og skjermstørrelse. Nå her er det to alternativer for hvordan du tilnærmer deg design / utvikling.

Du kan velge å ha forskjellige UI / UX avhengig av skjermstørrelse. Dette er sannsynligvis det beste alternativet for de fleste typer applikasjoner, men krever mye innsats fordi det er flere skjermer som skal designes og implementeres. Skjermstørrelse kan identifiseres via Dimensions API. Alternativt kan du bruke en tredjepartspakke som gir noen verktøy utenfor boksen, for eksempel React Native Responsive UI.

Eller du kan velge å ha samme brukergrensesnitt / UX som skalerer proporsjonalt for alle skjermstørrelser. Dette er det beste alternativet når du for eksempel utvikler et spill. Igjen, kan du bruke en tredjepartspakke for å oppnå det som for eksempel React Native Responsive Screen.

Ansvarsfraskrivelse: Jeg er produsenten av pakken React Native Responsive Screen.

Gå til animasjoner med forsiktighet

Animasjoner er veldig viktige for mobilapper, men ytelsen til React Native er ikke på sitt aller beste ennå.

For å beskytte dere mot å levere dårlige resultater, må du alltid teste animasjoner i enheten - emulator gir ikke riktig tilbakemelding. Du må også benytte deg av prop. UseNativeDriver (med verdi satt til true) der du kan, fordi det vil hjelpe deg å oppnå bedre ytelse.

For flere tips om hvordan du oppnår bedre ytelse, ser du på denne forrige artikkelen om meg.

Husk også ...

  1. React Native har ikke DOM-elementer. I stedet har vi å gjøre med innfødte elementer.
  2. Om CSS:
  • Ikke alle egenskapene støttes; i det minste ikke ennå. Sjekk dokumentasjonen for mer info: Vis stilutstyr, bildestiluttrekkere, tekststileruttrekk
  • Kortsiktige egenskaper fungerer ikke bra, så foretrekker alltid de spesifikke (dvs. margin-bunn, margin-topp, margin-venstre, margin-høyre i stedet for margin)
  • Ikke alle egenskaper støtter prosentverdier. For å nevne noen få: margin, border-bredde og border-radius. Og hvis noen prøver å sette en prosentverdi, vil RN enten ignorere den fullstendig, eller programmet vil krasje.
  • RN gir fleksibel støtte ut av esken. Lær det og bruk når du kan. Det er din beste CSS-allierte!

Hva tror du?

Hva synes du om denne artikkelen? Hvilke andre gode fremgangsmåter har du i tankene? Gi perspektivet og ideene dine i kommentarfeltet nedenfor.

Hvis du likte denne artikkelen, kan du trykke på klappknappen for å hjelpe andre med å finne den.

Om meg

Hei, jeg er Tasos; en programvareingeniør som elsker nett og for tiden jobber mye med React Native og React. Jeg er grunnlegger av programvarebyrået Coded Lines der vi gjennomfører ende-til-ende mobil- og nettprosjekter med vekt på markedsføring i appen. Hvis det høres ut hva du leter etter, kan du kontakte meg her: tasos.maroudas@codedlines.com. Takk for at du var innom :)

___________________________________________________________________

Takk

George Karboulonis for korrekturlesing