Kā efektīvi pārvaldīt stāvokli React

Ja esat uzrakstījis daudz React koda, iespējams, ka esat izmantojis stāvokli nepareizi. Viena izplatīta kļūda, ko pieļauj daudzi React izstrādātāji, ir stāvokļu globāla glabāšana lietojumprogrammā, nevis to glabāšana komponentos, kur tie tiek izmantoti.

Uzziniet, kā varat pārveidot savu kodu, lai izmantotu vietējo stāvokli, un kāpēc tas vienmēr ir laba ideja.

Reakcijas stāvokļa pamatpiemērs

Šeit ir ļoti vienkārša skaitītāja lietojumprogramma kas parāda, kā statuss parasti tiek apstrādāts programmā React:

imports {useState} no'reaģēt'
imports {Counter} no'skaitītājs'
funkcijuApp(){
konst [count, setCount] = useState(0)
atgriezties<Skaitītājsskaitīt={count}setCount={setCount} />
}
eksportētnoklusējuma App

1. un 2. rindā jūs importējat useState() āķis valsts izveidei, un Skaitītājs komponents. Jūs definējat skaitīt valsts un setCount stāvokļa atjaunināšanas metode. Tad jūs nododat abus uz Skaitītājs komponents.

The Skaitītājs komponents pēc tam atveido skaitīt un zvani setCount lai palielinātu un samazinātu skaitu.

funkcijuSkaitītājs({count, setCount}) {
atgriezties (


 setCount(iepriekj => iepriekšējais - 1)}>-</button>
{count}</span>
 setCount(iepriekj => iepriekšējā + 1)}>+</button>
 </div>
 )
}

Jūs neesat definējis skaitīt mainīgs un setCount darbojas lokāli iekšpusē Skaitītājs komponents. Drīzāk jūs to nodevāt no vecākkomponenta (App). Citiem vārdiem sakot, jūs izmantojat globālu stāvokli.

Problēma ar globālajām valstīm

Globālā stāvokļa izmantošanas problēma ir tāda, ka jūs saglabājat stāvokli vecākkomponentā (vai vecāka komponentā) un pēc tam nododot to kā rekvizītus komponentam, kur šis stāvoklis faktiski ir vajadzīgs.

Dažreiz tas ir labi, ja jums ir stāvoklis, kas ir kopīgs daudziem komponentiem. Bet šajā gadījumā neviena cita sastāvdaļa nerūp skaitīt valsts, izņemot Skaitītājs komponents. Tāpēc labāk ir pārcelt valsti uz Skaitītājs komponents, kur tas faktiski tiek izmantots.

Valsts pārvietošana uz bērnu komponentu

Kad pārvietojat stāvokli uz Skaitītājs komponents, tas izskatītos šādi:

imports {useState} no'reaģēt'
funkcijuSkaitītājs() {
konst [count, setCount] = useState(0)
atgriezties (


 setCount(iepriekj => iepriekšējais - 1)}>-</button>
{count}</span>
 setCount(iepriekj => iepriekšējā + 1)}>+</button>
 </div>
 )
}

Tad jūsu iekšienē App komponents, jums nekas nav jānodod uz Skaitītājs komponents:

// imports
funkcijuApp(){
atgriezties<Skaitītājs />
}

Skaitītājs darbosies tieši tāpat kā iepriekš, taču lielā atšķirība ir tā, ka visi jūsu štati ir lokāli šajā Skaitītājs komponents. Tātad, ja jums ir nepieciešams vēl viens skaitītājs mājaslapā, jums ir divi neatkarīgi skaitītāji. Katrs skaitītājs ir autonoms un rūpējas par visu savu stāvokli.

Stāvokļa apstrāde sarežģītākās lietojumprogrammās

Cita situācija, kurā izmantotu globālu stāvokli, ir veidlapas. The App zemāk esošais komponents nodod veidlapas datus (e-pastu un paroli) un iestatīšanas metodi Pieteikšanās forma komponents.

imports { useState } no"reaģēt";
imports { Pieteikšanās forma } no"./Pieteikšanās forma";
funkcijuApp() {
konst [formData, setFormData] = useState({
 e-pasts: "",
 parole: "",
 });
funkcijuupdateFormData(jauniDati) {
 setFormData((iepriekj) => {
atgriezties { ...iepriekšējais, ...jaunieDati };
 });
 }
funkcijuonSubmit() {
konsole.log (formData);
 }
atgriezties (
 data={formData}
 updateData={updateFormData}
 onSubmit={onSubmit}
 />
 );
}

The Pieteikšanās forma komponents uzņem pieteikšanās informāciju un atveido to. Kad iesniedzat veidlapu, tā izsauc updateData funkcija, kas tiek nodota arī no vecākkomponenta.

funkcijuPieteikšanās forma({ onSubmit, data, updateData }) {
funkcijurokturisIesniegt(e) {
 e.preventDefault();
 onSubmit();
 }
atgriezties (


"e-pasts">E-pasts</label>
 tips="e-pasts"
 id="e-pasts"
 value={data.email}
 onChange={(e) => updateData({ e-pasts: e.target.value })}
 />
"parole">Parole</label>
 tips="parole"
 id="parole"
 value={data.password}
 onChange={(e) => updateData({ parole: e.target.value })}
 />
"Iesniegt">Iesniegt</button>
 </form>
 );
}

Tā vietā, lai pārvaldītu vecākkomponenta stāvokli, labāk ir pārvietot stāvokli uz LoginForm.js, kur izmantosit kodu. Šādi rīkojoties, katrs komponents kļūst autonoms un nav atkarīgs no cita komponenta (t.i., vecāku). Šeit ir modificētā versija Pieteikšanās forma:

imports { useRef } no"reaģēt";
funkcijuPieteikšanās forma({ onSubmit }) {
konst emailRef = useRef();
konst passwordRef = useRef();

funkcijurokturisIesniegt(e) {
 e.preventDefault();
 onSubmit({
 e-pasts: emailRef.current.value,
 parole: passwordRef.current.value,
 });
 }
atgriezties (


"e-pasts">E-pasts</label>
"e-pasts" id="e-pasts" ref={emailRef} />
"parole">Parole</label>
"parole" id="parole" ref={passwordRef} />
"Iesniegt">Iesniegt</button>
 </form>
 );
}

Šeit jūs saistāt ievadi ar mainīgo, izmantojot ref atribūti un useRef Reaģējiet, nevis tieši nododiet atjaunināšanas metodes. Tas palīdz noņemt detalizētu kodu un optimizējiet veidlapas veiktspēju, izmantojot useRef āķi.

Vecākā komponentā (App.js), varat noņemt gan globālo stāvokli, gan updateFormData() metodi, jo jums tā vairs nav vajadzīga. Atliek tikai funkcija onSubmit(), kuru jūs izsaucat no iekšpuses Pieteikšanās forma komponents, lai reģistrētu pieteikšanās informāciju konsolē.

funkcijuApp() {
funkcijuonSubmit(formData) {
konsole.log (formData);
 }
atgriezties (
 data={formData}
 updateData={updateFormData}
 onSubmit={onSubmit}
 />
 );
}

Jūs ne tikai padarījāt savu štatu pēc iespējas lokālāku, bet arī faktiski novērsāt vajadzību pēc jebkura štata (un izmantojāt refs vietā). Tātad jūsu App komponents ir kļuvis ievērojami vienkāršāks (tam ir tikai viena funkcija).

Jūsu Pieteikšanās forma komponents kļuva arī vienkāršāks, jo jums nebija jāuztraucas par stāvokļa atjaunināšanu. Drīzāk jūs vienkārši sekojat līdzi diviem refs, un viss.

Kopīgā stāvokļa apstrāde

Ir viena problēma saistībā ar pieeju, lai mēģinātu padarīt valsti pēc iespējas lokālāku. Jūs bieži saskaraties ar scenārijiem, kad vecākkomponents neizmanto stāvokli, bet nodod to vairākiem komponentiem.

Piemērs ir a TodoContainer vecākkomponents ar diviem pakārtotajiem komponentiem: Darāmo lietu saraksts un TodoCount.

funkcijuTodoContainer() {
konst [todos, setTodos] = useState([])
atgriezties (
 <>


 </>
 )
}

Abām šīm bērnu sastāvdaļām ir nepieciešams todos valsts, tātad TodoContainer nodod to abiem. Tādos scenārijos kā šie, jums ir jāpadara valsts pēc iespējas lokālāka. Iepriekš minētajā piemērā ievietojot to iekšpusē TodosContainer ir tik vietējais, cik vien iespējams.

Ja jūs liktu šo stāvokli savā App komponents, tas nebūtu tik lokāls, cik vien iespējams, jo tas nav tuvākais vecākiem diviem komponentiem, kuriem nepieciešami dati.

Lieliem lietojumiem, pārvaldot stāvokli tikai ar useState() āķis var izrādīties grūts. Šādos gadījumos jums var būt nepieciešams izvēlēties React Context API vai Reaģējiet uz Redux efektīvi pārvaldīt valsti.

Uzziniet vairāk par React Hooks

Āķi veido React pamatu. Izmantojot āķus programmā React, varat izvairīties no gara koda rakstīšanas, kas citādi izmantotu klases. UseState() āķis neapšaubāmi ir visbiežāk izmantotais React āķis, taču ir arī daudzi citi, piemēram, useEffect(), useRef() un useContext().

Ja vēlaties apgūt lietojumprogrammu izstrādi, izmantojot React, jums jāzina, kā izmantot šos āķus savā lietojumprogrammā.