Hvor skal man reagere Komponentdata: tilstand, opbevaring, statisk og dette

Hvor skal man reagere Komponentdata: tilstand, opbevaring, statisk og dette

Med fremkomsten af ​​React og Redux er der opstået et fælles spørgsmål:

Hvad skal jeg opbevare i Redux- butikken, og hvad skal jeg gemme i lokal stat ?

Men dette spørgsmål er faktisk for forenklet, fordi der også er to andre måder, du kan gemme data til brug i en komponent: statisk og dette .

Lad os gå over, hvad hver af disse, og hvornår du skal bruge dem.

Lokal stat

Da React først blev introduceret, blev vi præsenteret for den lokale stat . Den vigtige ting at vide om den lokale stat er, at når en tilstandsværdi ændres, udløser den en gengivelse.

Denne tilstand kan overføres til børn som rekvisitter , hvilket giver dig mulighed for at adskille dine komponenter mellem smarte datakomponenter og dumme præsentationskomponenter, hvis du vælger.

Her er en grundlæggende tæller-app, der bruger lokal stat :

Dine data (tællerens værdi) gemmes i App- komponenten og kan videregives til sine børn.

Brug sager

Forudsat at din tæller er vigtig for din app og lagrer data, der ville være nyttige for andre komponenter, ville du ikke bruge den lokale tilstand til at beholde denne værdi.

Den nuværende bedste praksis er at bruge lokal tilstand til at håndtere tilstanden i din brugergrænseflade (UI) i stedet for data. For eksempel er det en perfekt gyldig brug af en lokal stat at bruge en kontrolleret komponent til at udfylde en formular .

Et andet eksempel på UI-data, som du kunne gemme i lokal tilstand, ville være den aktuelt valgte fane fra en liste over muligheder.

En god måde at tænke på, hvornår man skal bruge den lokale stat, er at overveje, om den værdi, du gemmer, vil blive brugt af en anden komponent. Hvis en værdi kun er specifik for en enkelt komponent (eller måske et enkelt barn af den pågældende komponent), er det sikkert at holde denne værdi i lokal tilstand .

Takeaway: Gem UI-tilstand og forbigående data (såsom formularindgange) i lokal tilstand .

Redux butik

Derefter efter nogen tid var gået, og alle begyndte at blive fortrolige med ideen om envejs datastrøm, fik vi Redux.

Med Redux får vi en global butik . Denne butik lever på det højeste niveau i din app og videregiver data til alle børn. Du opretter forbindelse til den globale butik med connect wrapper og en mapStateToProps- funktion.

Først satte folk alt i Redux- butikken . Brugere, modeller, formularer, stikkontakter ... du hedder det.

Nedenfor er den samme tæller-app, men bruger Redux. Det vigtige at bemærke er, at tælleren nu kommer fra this.props.counter efter at være blevet kortlagt fra mapStateToProps i tilslutningsfunktionen , som tager tællerværdien fra den globale butik og kortlægger den til den aktuelle komponents rekvisitter .

Nu når du klikker på knappen, sendes en handling, og den globale butik opdateres. Dataene håndteres uden for vores lokale komponent og videregives.

Det er værd at bemærke, at når rekvisitter opdateres, udløser det også en gengivelse - ligesom når du opdaterer tilstanden .

Brug sager

Redux- butikken er fantastisk til at holde applikationstilstand snarere end UI-tilstand. Et perfekt eksempel er en brugers loginstatus. Mange af dine komponenter har brug for adgang til disse oplysninger, og så snart login-status ændres, skal alle disse komponenter (i det mindste dem, der gengives) gengives med de opdaterede oplysninger.

Redux er også nyttig til at udløse begivenheder, som du har brug for adgang til på flere komponenter eller på tværs af flere ruter. Et eksempel på dette ville være et login-modal, som kan udløses af et stort antal knapper overalt i din app. I stedet for at gengive et modal på et dusin steder betinget, kan du gengive det på øverste niveau i din app og bruge en Redux-handling til at udløse det ved at ændre en værdi i butikken .

Takeaway : Gem data, som du har til hensigt at dele på tværs af komponenter, i butikken .

dette.

En af de mindst anvendte funktioner, når du arbejder med React, er dette . Folk glemmer ofte, at React bare er JavaScript med ES2015-syntaks. Alt hvad du kan gøre i JavaScript, kan du også gøre i React.

Eksemplet nedenfor er en funktionel tæller-app svarende til de to eksempler ovenfor.

Vi lagrer tællerværdien i komponenten og bruger forceUpdate () til at gengive igen, når værdien ændres. Dette skyldes, at ændringer til andet end tilstand og rekvisitter ikke udløser en gengivelse .

Dette er faktisk et eksempel på, hvordan du ikke skal bruge dette . Hvis du finder dig selv ved at bruge forceUpdate () , laver du sandsynligvis noget forkert. For værdier, som en ændring skal udløse en gengivelse for, skal du bruge lokal tilstand eller rekvisitter / Redux- butik .

Brug sager

Brugssagen til dette er at gemme værdier, for hvilke en ændring ikke skal udløse en gengivelse. For eksempel er stikkontakter en perfekt ting at gemme på dette .

Også mange mennesker er ikke klar over, at de allerede bruger dette hele tiden i deres funktionsdefinitioner. Når du definerer gengivelse () , definerer du virkelig denne.prototype.render = funktion () , men den er skjult bag syntaks for ES2015-klassen.

Takeaway: Brug dette til at gemme ting, der ikke bør udløse en gengivelse.

Statisk

Statiske metoder og egenskaber er måske det mindst kendte aspekt af ES2015-klasser (rolig, ja, jeg ved, de er ikke rigtig klasser under emhætten) , for det meste fordi de ikke bruges så ofte. Men de er faktisk ikke særlig komplicerede. Hvis du har brugt PropTypes , har du allerede defineret en statisk egenskab.

De følgende to kodeblokke er identiske. Den første er, hvordan de fleste mennesker definerer PropTypes. Det andet er, hvordan du kan definere dem med statisk .

Som du kan se, er statisk ikke så kompliceret. Det er bare en anden måde at tildele en værdi til en klasse. Den største forskel mellem statisk og dette er, at du ikke behøver at instantiere klassen for at få adgang til værdien.

I eksemplet ovenfor kan du se, at for at få staticProperty- værdien kunne vi bare kalde det direkte fra klassen uden at instantere det, men for at få prototypeProperty var vi nødt til at instantiere det med ny App () .

Brug sager

Statiske metoder og egenskaber anvendes sjældent og skal bruges til hjælpefunktioner, som alle komponenter af en bestemt type har brug for.

PropTypes er et eksempel på en hjælpefunktion, hvor du vil knytte til noget som en knapkomponent , da hver knap, du gengiver, har brug for de samme værdier.

En anden brugssag er, hvis du er bekymret for overhentning af data. Hvis du bruger GraphQL eller Falcor, kan du angive, hvilke data du vil have tilbage fra din server. På den måde modtager du ikke meget mere data, end du faktisk har brug for til din komponent.

Så i eksempelkomponenten ovenfor kunne du hurtigt få en række krævede værdier til din forespørgsel med App.requiredData , før du anmoder om data for en bestemt komponent . Dette giver dig mulighed for at fremsætte en anmodning uden overhentning.

Takeaway: du kommer sandsynligvis aldrig til at bruge statisk .

Den anden mulighed ...

Der er faktisk en anden mulighed, som jeg med vilje har udeladt fra titlen, fordi du skal bruge den sparsomt: du kan gemme ting i en modul-scoped variabel .

Der er specifikke situationer, hvor det giver mening, men for det meste skal du bare ikke gøre det.

Du kan se, at dette er næsten det samme som at bruge dette, bortset fra at vi gemmer værdien uden for vores komponent, hvilket kan forårsage problemer, hvis du har mere end en komponent pr. Fil. Du kan muligvis bruge dette til at indstille standardværdier, hvis værdierne ikke er bundet til din butik , ellers ville det være bedre at bruge statisk til standardrekvisitter.

Hvis du har brug for at dele data på tværs af komponenter og ønsker at holde data tilgængelige for alt modulet, er det næsten altid bedre at bruge din Redux- butik .

Takeaway: Brug ikke modul-scoped variabler, hvis du kan undgå det.

Sam Corcos er hovedudvikler og medstifter af Sightline Maps, den mest intuitive platform til 3D-udskrivning topografiske kort samt LearnPhoenix.io, et mellem-avanceret tutorialsite til opbygning af skalerbare produktionsapps med Phoenix og React. Få $ 20 i rabat på LearnPhoenix med kuponkoden: free_code_camp