Mobx React - bedste praksis

I denne artikel vil jeg vise dig almindelige bedste fremgangsmåder til brug af React med mobx. Jeg vil præsentere dem som regler. Så når du kommer til et specifikt problem, så prøv at løse det, mens du holder dig til disse regler.

Denne artikel kræver, at du har en grundlæggende forståelse af butikker i mobx. Hvis ikke, skal du læse dette først.

Brug for en hurtigstart? Jeg oprettede et startprojekt, der implementerer den anbefalede praksis. https://github.com/danielbischoff/react-mobx-starter

Butikkerne repræsenterer ui-staten

Husk altid, at butikkerne repræsenterer din applikations ui-tilstand. Det betyder, at når du gemmer dine butikker 'tilstand i en fil, lukker dit program og genstarter det med den indlæste tilstand, vil du have det samme program og se de samme ting, som du har set før du lukker dit program. Butikker er ikke beregnet til at være 'lokale databaser'. De indeholder også oplysninger om, hvilken knap der er synlig, deaktiveret, den aktuelle tekst til et arkiveret input osv.

Adskill dine hvileopkald fra butikkerne

Ring ikke til din hvile-grænseflade indefra i dine butikker. Dette gør dem svære at teste. I stedet for at sætte disse hvileopkald i ekstra klasser og videregive disse tilfælde til hver butik ved hjælp af butikens konstruktør. Når du skriver test, kan du nemt falske disse api-opkald og videregive din falske api-forekomst til hver butik.

Opbevar din forretningslogik i butikkerne

Skriv aldrig forretningslogik i dine komponenter. Når du skriver din forretningslogik i komponenter, har du ingen chance for at genbruge den, din forretningslogik spreder sig over mange komponenter, hvad der gør det svært at refaktorere eller genbruge koden. Skriv forretningslogikken med metoder i butikkerne, og ring disse metoder fra dine komponenter.

Opret ikke globale butikstilstande

Opret aldrig globale butikstilstande. Du kan ikke skrive nogen fornuftige og pålidelige test for dine komponenter. Brug i stedet leverandøren til at injicere dine butikker i dine komponenter rekvisitter. Derefter kan du i dine test nemt bespotte disse butikker.

Kun butikken har tilladelse til at ændre dens egenskaber

Skift aldrig en butiks ejendom direkte i en komponent. Kun butikken har tilladelse til at ændre sine egne egenskaber. Ring altid en metode fra butikken, der ændrer butikens ejendom. Ellers opdateres din applikationstilstand (butikker = applikationstilstand) overalt, og du mister langsomt kontrollen. Det gør det meget svært at fejlsøge.

Kommenter altid hver komponent med @ observatør

Ved at kommentere hver komponent med @ -observatør kan hver komponent opdatere på butikspropændringer. Ellers skal den overordnede komponent, der er kommenteret med @ -komponenten, gendannes for at opdatere dens underordnede komponent. Så mindre komponenter skal genudleveres.

Brug @ beregnet

Lad os sige, at du vil have din knap deaktiveret, når en bruger ikke har administratorrollen, og applikationen ikke er i "admin-tilstand". En enkelt egenskab som isAdmin i en butik er ikke nok til dette. Du har brug for en beregnet ejendom i din butik.

Du har sandsynligvis ikke brug for reaktionsrouter

Du har sandsynligvis ikke brug for reaktionsrouter. Som jeg sagde før, vil du have, at dine butikker skal repræsentere din applikations tilstand. Når du lader reaktionsrouter håndtere en del af din applikationstilstand, lader du ikke dine butikker repræsentere applikationstilstanden. Så hold din aktuelle visning i en ejendom i en af ​​dine butikker. Så har du en komponent, der bare gengiver, hvad ejendommen siger.

Forsøg at favorisere kontrollerede komponenter frem for ukontrollerede komponenter

Forsøg altid at opbygge kontrollerede komponenter. Dette gør testkomponenter og den samlede kompleksitet af dine komponenter let at håndtere.

Jeg håber, jeg kunne hjælpe dig med disse enkle tip.
Stil spørgsmål eller giv feedback i kommentarerne herunder.