Kuidas saada React setState () abil 10 minutiga profiks

See artikkel on suunatud inimestele, kellel on Reacti suhtes juba esimene lähenemisviis ja kes algajatena kahtlevad setStatetoimimises ja selle õiges kasutamises. See peaks aitama ka keskmistel ja vanematel arendajatel kasutada oleku seadmiseks puhtamaid ja abstraktsemaid viise ning panna kõrgema järgu funktsioonid käituma ja abstraktsesse olekusse.

Lihtsalt lugege ja nautige!

Nii et haara tass kohvi ja loe edasi! ?

SetState () põhimõisted

React Components võimaldab teil kasutajaliidese (UI) jagada iseseisvateks, korduvkasutatavateks tükkideks, et saaksite mõelda igale tükile eraldi.

Kontseptuaalselt on komponendid nagu JavaScripti funktsioonid. Nad aktsepteerivad suvalisi sisendeid (nn rekvisiite) ja tagastavad React elemendid, mis kirjeldavad ekraanil kuvatut.

Kui peate andma kasutajale võimaluse midagi sisestada või muuta mingil viisil muutujaid, mida komponent rekvisiidina saab, peate seda tegema setState.

Ükskõik, kas deklareerite komponendi funktsiooni või klassina, ei tohi see kunagi oma rekvisiite muuta.

Kõik reageerivad komponendidpeavad oma rekvisiitide suhtes käituma nagu puhtad funktsioonid. See tähendab funktsioone, mis ei püüa kunagi oma sisendeid muuta ja tagastavad samade sisendite puhul alati sama tulemuse.

Muidugi on rakenduse kasutajaliidesed dünaamilised ja aja jooksul muutuvad. Sellepärast stateloodi.

State võimaldab React komponentidel muuta aja jooksul oma väljundit vastuseks kasutaja toimingutele, võrgu vastustele ja muule, seda reeglit rikkumata.

Klassidena määratletud komponentidel on mõned täiendavad funktsioonid. Kohalik olek on funktsioon, mis on saadaval ainult klassi komponentidele.

setState on teegiga kaasas olev API-meetod, et kasutaja saaks olekut aja jooksul määratleda ja manipuleerida.

Kolm reeglit pöidla kasutamisel setState ()

Ärge muutke olekut otse

Osariigi värskendused võivad olla asünkroonsed

Reageerimine võib setState()toimivuse huvides pakkida mitu kõnet ühte värskendusse.

Kuna this.props ja this.statevõib ajakohastada asünkroonselt, siis ei tohiks tugineda nende väärtuste arvutamiseks järgmise riik.

Sa peaksid alati teha sellist manipuleerimist funktsionaalset lähenemist, esitades stateja propsning tagastades uue statepõhineb endise.

Olekuvärskendused on ühendatud

Kui helistate setState(), ühendab Reageerige teie pakutava objekti praegusesse state.

Allpool toodud näites värskendame muutujat dogNeedsVaccinationmuudest statemuutujatest sõltumatult .

Ühendamine on madal, nii this.setState({ dogNeedsVaccination: true }) et muud muutujad jäävad puutumatuks, asendades ainult väärtuse dogNeedsVaccination.

Austage andmevoogu ja vältige maksimumarvu

Andmed voolavad alla! Kumbki vanema ega lapse komponent ei saa teada, kas teatud komponent on riiklik või kodakondsuseta, ja neil ei tohiks olla vahet, kas see on määratletud funktsiooni või klassina.

Sellepärast statenimetatakse seda sageli kohalikuks või kapseldatuks. Sellele ei pääse juurde muud komponendid kui see, mis selle omab ja seab.

Kui teete setStaterekvisiiti ja kasutate seda oma komponendis, rikute renderdamise rekvisiitide voogu. Kui mingil põhjusel teie komponenti kantud rekvisiit vanemkomponendis muutus, ei renderda laps seda automaatselt maagiliselt?

Kontrollime näidet:

Siin on teil Homekomponent, mis genereerib maagilise numbri iga 1000 ms kohta ja määrab selle oma state.

Pärast seda renderdatakse see number ja kutsutakse kolm Childkomponenti (õde-venda), kes saavad maagilise numbri, et kuvada see kolme erineva lähenemisviisi abil:

Esimene lähenemine

Komponent ChildOfHomeaustab React propsi kaskaadivoogu ja arvestades, et eesmärk on näidata ainult maagilist numbrit, renderdab see propssaadud otse.

Teine lähenemine

Komponent ChildOfHomeBrothersaab propsvanema käest ja componentDidMountmäärab maagia numbri state. Siis muudab see state.magicNumber.

See näide ei tööta, kuna render()ei tea, et a prop on muutunud, mistõttu see ei käivita komponendi uuesti renderdamist. Kuna komponenti enam ei renderdata, siis componentDidMountseda ei kutsuta ja kuva ei värskendata.

Kolmas lähenemine

Tavaliselt arvame, et kui mõni teine ​​lähenemisviis töötab, siis midagi on puudu. Selle asemel, et samm tagasi astuda, lisame koodile asju, et see toimiks!

Nii et selles kolmandas lähenemises oleme lisanud, componentDidUpdateet kontrollida, kas propskomponendi uuesti renderdamise käivitamiseks on muudatusi tehtud. See pole vajalik ja viib meid ebapuhta koodi juurde. See toob endaga kaasa ka jõudluskulud, mis korrutatakse mitu korda, kui me seda suures rakenduses teeme, kus meil on palju aheldatud komponente ja kõrvaltoimeid.

See on vale, välja arvatud juhul, kui peate lubama kasutajal saadud pakkumise väärtust muuta.

Kui te ei pea rekvisiidi väärtust muutma, proovige alati asjad toimida vastavalt React voogule (esimene lähenemine).

Töötavat veebisaiti saate vaadata selle näite abil, mille olen teile Glitchis ette valmistanud. Vaatama ja lõbutsema?

Vaadake ka selle artikli kohta minu repos olevat koodi Home.jsja HomeCodeCleaned.js(ilma HTML-kraamita).

Kuidas seadaState

Nii et praegusel hetkel arvan, et on aeg meie käed määrida!

Mängime sellega natuke setStateja parandame seda! Lihtsalt jälgi ja haara veel üks tass kohvi!

Loome kasutajaandmete värskendamiseks väikese vormi:

Siin on ülaltoodud näite kood:

Oleme seadnud stateobjektiks ja pole probleemi, sest meie praegune olek ei sõltu meie viimasest olekust.

Mis siis, kui loome perekonnanime tutvustamiseks ja kuvamiseks veel ühe vormivälja?

Tore! Oleme abstraktse handleFormChangemeetodi abil suutnud käsitleda kõiki sisendvälju ja setState.

Mis siis, kui lisame andmete õigeks või kehtetuks märkimiseks lülitusnupu ja loenduri, et teada saada, mitu muudatust olekus oleme teinud?

Jah! Me rokime! Oleme abstraktselt palju asju kokku puutunud!

Hmmm ... Oletame, et ma ei taha isValidmuutuja juhtimiseks märkeruudu, vaid lihtsat lülitusnuppu.

Eraldame sellest meetodist ka loenduri käitleja. See töötab hästi, kuid keerukamates olukordades, kus Reactil tuleb muudatused pakkida / grupeerida, ei ole hea poliitika tugineda this.state.countermuutujale selle lisamiseks. See väärtus võib muutuda, ilma et te oleksite sellest teadlikud.

Me kasutame selle madalat koopiat kohe, kui operatsioon käivitatakse, ja sel ajahetkel te ei tea, kas selle väärtus on see, mida ootasite või mitte!

Lähme natuke funktsionaalseks!

Okei - me oleme kaotanud abstraktsiooni, kuna oleme käitlejad lahutanud, kuid see on hea põhjus!

Nii et praegu hoiame handleFormChangeobjekti edastamist setStateAPI meetodile. Kuid meetodid handleCounterja handleIsValidmeetodid on nüüd funktsionaalsed ning alustavad praeguse oleku haaramisest ja siis, olenevalt sellest olekust, selle järgmiseks muutmiseks.

See on õige viis stateeelmisest olekust sõltuvate muutujate muutmiseks .

Mis siis, kui me tahame console.log()riigi muudatusi firstNameja lastNamesisestamise vormid iga kord muutus toimub? Proovime järele!

Tore! Iga kord, kui see handleFormChangetoimub (mis tähendab, et juhtus uus klahvivajutus), logFields()kutsutakse meetodit ja logitakse praegune olek konsooli!

Kontrollime brauseri konsooli:

Oota! Mis siin juhtus, inimesed? Konsoolilogi on üks muudatus enne praeguse vormi sisestamist! Miks see juhtub?

setState on asünkroonne !!

Me teadsime seda juba, kuid nüüd näeme seda oma silmaga! Mis seal toimub? Vaatame ülaltoodud handleFormChangeja logFieldsmeetodeid.

Nii saab handleFormChangemeetod sündmuse nime ja väärtuse, seejärel teeb setStateneist andmetest a. Seejärel kutsub see handleCounterloenduri teabe värskendamiseks ja kutsub logFieldsmeetodi lõpuks üles . logFieldsMeetod haarab currentStateja naaseb "Eduard" asemel "Eduardo".

Asi on: setStateon asünkroonne ja ei tegutse hetkel. React teeb oma tööd ja täidab logFieldsmeetodi kõigepealt, lahkudes setStatejärgmisele sündmuse tsüklile.

Kuid kuidas saaksime sellist olukorda vältida?

Noh, setStateAPI-l on callbackselle olukorra vältimiseks:

Kui tahame, et logFields()see võtaks arvesse hiljutisi muudatusi, mida olekus oleme teinud, peame selle tagasihelistamisel kasutama järgmiselt:

Olgu, nüüd see töötab!

Me ütleme Reactile: “Hei, reageeri! Hoiduge, et kui kasutate logFieldsmeetodit, tahan, et teil oleks statejuba värskendatud korras? Ma usaldan sind!"

React ütleb: „Okei Edo! Ma hakkan tegelema kogu selle partiiga, mida tavaliselt setStatekoduhoovis asjaga tegelen ja alles siis, kui olen sellega valmis, siis kutsun üles logFields()! Lahe mees! Lõdvestu! "

Ja tegelikult - see töötas!

Okei kõigile! Selleks ajaks oleme hakkama saanud suuremate lõkse setState.

Kas teil on julgust müürist kaugemale minna? Haara tass kohvi ja lähme tõeliselt kewli ...

SetState () abil väljamõeldis

Nüüd, kui meil handleCounterja handleIsValidmeetodeid ning setState()väljendada funktsioonid, saame koostada riigi uuendatud muude funktsioonidega! Mulle meeldib kompositsioon! Lähme mõnusalt!

Me võime viia sees oleva loogika setStatefunktsiooni, mis asub väljaspool klassi komponenti. Nimetagem seda toggleIsValid. ☝️

Nüüd saab see funktsioon elada väljaspool klassi komponenti ja kõikjal teie rakenduses.

Mis siis, kui kasutame kõrgema järgu funktsiooni?

Vau! Nüüd ei kasuta me toggleIsValidenam seda funktsiooni. Kutsume üles abstraktset kõrgema järgu funktsiooni, mida kutsutakse, toggleKeyja edastame sinna võtme (antud juhul stringi).

Kuidas peame toggleIsValidfunktsiooni kohe muutma ?

Mida?! Nüüd on meil funktsioon nimega, toggleKeymis võtab vastu a keyja tagastab uue funktsiooni, mis muudab olekut vastavalt tarnitud võtmele.

See toggleKeyvõib olla teegis või abifailis. Seda saab kasutada paljudes erinevates kontekstides, et muuta oleku, mida soovite, vastupidiseks.

Suurepärane!

Teeme sama juurdekasvu loenduri käitlejaga:

Jah! See töötab! Nii kena. Läheme nüüd hulluks ...

Kuu laskmine ja tagasitulek

Mis siis, kui loome üldfunktsiooni, makeUpdatermis võtab vastu teisendusfunktsiooni, mida soovite rakendada, võtab võtme ja tagastab olekut haldava olekufunktsiooni koos teisendusfunktsiooni ja võtmega? Natuke segaduses? Lähme!

Ok, sellest piisab ... Peatume siin. ?

Selles GitHubi repos saate kontrollida kogu koodi, mille oleme teinud.

Viimane, kuid mitte vähem

Ärge unustage oleku maksimaalsest kasutamisest hoidumist ja React renderdamise rekvisiitide kaskaadi austamist.

Ärge unustage, et see setStateon asünkroonne.

Ärge unustage, et setStatesaate objekti või funktsiooni

Ärge unustage, et peaksite funktsiooni läbima siis, kui teie järgmine olek sõltub teie eelmisest olekust.

Bibliograafia

  1. Reageeri dokumentatsiooniga
  2. Ryan Florence'i Reach Techi kursused, mida ma tõesti soovitan.

Tänan teid väga!