Mobx React - beste praksis

I denne artikkelen vil jeg vise deg vanlige beste fremgangsmåter for bruk av React with mobx. Jeg vil presentere dem som regler. Så når du kommer til et spesifikt problem, kan du prøve å løse det mens du holder deg til disse reglene.

Denne artikkelen krever at du har en grunnleggende forståelse av butikker i mobx. Hvis ikke, les dette først.

Trenger du en hurtigstart? Jeg opprettet et startprosjekt som implementerer anbefalt praksis. https://github.com/danielbischoff/react-mobx-starter

Butikkene representerer ui-staten

Husk alltid at butikkene representerer applikasjonens ui-tilstand. Det betyr at når du lagrer butikkenes tilstand i en fil, lukker programmet og starter det på nytt med den lastede tilstanden, vil du ha det samme programmet og se de samme tingene, som du har sett før du lukket programmet. Butikker er ikke ment å være 'lokale databaser'. De har også informasjon om hvilken knapp som er synlig, deaktivert, den gjeldende teksten til en innlevering, etc.

Skill hvileanropene dine fra butikkene

Ikke ring hvilegrensesnittet ditt fra butikkene dine. Dette gjør dem vanskelig å teste. I stedet legger du disse hvileanropene i ekstra klasser og gir disse instansene til hver butikk ved bruk av butikkens konstruktør. Når du skriver test, kan du enkelt falske disse api-anropene og sende den falske api-forekomsten til hver butikk.

Hold din forretningslogikk i butikkene

Ikke skriv forretningslogikk i komponentene dine. Når du skriver din virksomhetslogikk i komponenter, har du ingen sjanser til å bruke den på nytt. Forretningslogikken din blir spredt over mange komponenter, det som gjør det vanskelig å refaktorere eller bruke koden på nytt. Skriv forretningslogikken med metoder i butikkene og ring disse metodene fra komponentene dine.

Ikke opprett globale butikkforekomster

Opprett aldri globale butikkforekomster. Du kan ikke skrive noen fornuftige og pålitelige tester for komponentene dine. Bruk i stedet leverandøren til å injisere butikkene dine i komponentrekvisitaene dine. Da kan du i testene dine lett spotte disse butikkene.

Bare butikken har lov til å endre sine egenskaper

Ikke endre en butiks eiendom direkte i en komponent. Bare butikken har lov til å endre sine egne eiendommer. Ring alltid en metode fra butikken, som endrer butikkens eiendom. Ellers oppdateres applikasjonsstatusen din (butikker = applikasjonsstatus) overalt, og du mister sakte kontrollen. Det gjør det veldig vanskelig å feilsøke.

Kommenter alltid hver komponent med @ observatør

Ved å kommentere hver komponent med @-observatør kan hver komponent oppdatere på butikkens prop-endringer. Ellers må den overordnede komponenten som er merket med @ -komponent gjenoppgi, for å oppdatere sin underordnede komponent. Så mindre komponenter trenger å bli gjengitt.

Bruk @ beregnet

La oss si at du vil at knappen din skal være deaktivert når en bruker ikke har administratorrollen og applikasjonen ikke er i "admin-modus". En enkelt eiendom som isAdmin i en butikk er ikke nok for dette. Du trenger en beregnet eiendom i butikken din.

Du trenger sannsynligvis ikke reagereruter

Du trenger sannsynligvis ikke reagereruter. Som jeg sa før vil du at butikkene dine skal representere søknadens tilstand. Når du lar reageringsruteren håndtere deler av søknadsstatusen din, lar du ikke butikkene dine representere søknadsstatusen. Så hold den nåværende visningen i en eiendom i en av butikkene dine. Så har du en komponent som bare gjengir det eiendommen sier.

Forsøk å foretrekke kontrollerte komponenter fremfor ukontrollerte komponenter

Forsøk alltid å bygge kontrollerte komponenter. Dette gjør det enkelt å teste komponenter og den generelle kompleksiteten til komponentene dine.

Jeg håper jeg kan hjelpe deg med disse enkle tipsene.
Still spørsmål eller gi tilbakemelding i kommentarene nedenfor.