- Gjendja e reagimit duhet të trajtohet si e pandryshueshme, me përditësime të kryera nëpërmjet përcaktuesve në vend të mutacionit të drejtpërdrejtë, veçanërisht për objektet dhe vargjet.
- Përditësimet e gjendjes janë asinkrone dhe mund të grumbullohen në grupe, kështu që përdorimi i përditësuesve funksionalë shmang problemet e gjendjes së vjetëruar në kohëmatës, mbylljet dhe ndërveprimet e shpejta.
- Komponentët e funksionit me Hooks (useState, useRef dhe miqtë) janë standardi modern, ndërsa mjete si React.memo dhe Immer ndihmojnë me performancën dhe të dhënat e ndërthurura.
- Ndarja e qartë e prop-eve dhe gjendjes, plus një model rrjedhjeje të të dhënave nga lart-poshtë, e mban sjelljen e komponentëve të parashikueshme ndërsa aplikacionet shkallëzohen.
Gjendja është një nga ato koncepte të React që duket i thjeshtë në sipërfaqe, por shpejt bëhet i ndërlikuar ndërsa aplikacioni juaj rritet. Filloni me një numërues të vogël, pastaj papritmas jeni duke xhongluar me fusha të shumta formulari, përditësime asinkrone, objekte të ndërthurura dhe probleme të performancës kur gjithçka ri-renderohet menjëherë. Të kuptuarit e thellë të gjendjes është ajo që e dallon dikë që "përdor React" nga dikush që mund të shkallëzojë dhe debugojë aplikacionet React të botës reale.
Në këtë udhëzues do të shqyrtojmë gjendjen aktuale në React (me qëllim lojën e fjalëve), nga përbërësit e klasës dhe metodat e ciklit jetësor deri te Hook-et moderne dhe përditësimet e pandryshueshme. Gjithashtu, do të shqyrtojmë tema delikate, por kritike, si përditësimet asinkrone, mbylljet e vjetra, kur të përdoret useRef në vend të useState dhe si ta mbani ndërfaqen tuaj të përdoruesit të parashikueshme. Qëllimi është t'ju japim një model të qartë mendor në mënyrë që komponentët tuaj të sillen pikërisht ashtu siç prisni.
Nga argumentet te deklarata: çfarë i takon në të vërtetë vendit?
Në thelb të çdo komponenti të React ekzistojnë dy burime kryesore të të dhënave: props dhe state. Props kalohen nga komponenti prind dhe mbeten të fiksuara për gjithë jetëgjatësinë e atij renderimi, ndërsa ishin është në pronësi dhe kontrollohet nga vetë komponenti dhe është menduar për të dhëna që ndryshojnë me kalimin e kohës.
Një rregull i mirë praktik është: nëse të dhënat konfigurohen nga jashtë dhe nuk ndryshojnë në këtë komponent, ato janë një prop; nëse komponenti duhet t'i gjurmojë dhe përditësojë ato, ato janë gjendje. Imagjinoni një komponent teksti që ndizet e fiket: teksti aktual jepet një herë (një prop), por pavarësisht nëse është aktualisht i shfaqur apo i fshehur, ndryshon vazhdimisht (gjendja). Ky dallim është ajo që i lejon React të mbajë rrjedhën e të dhënave tuaja të parashikueshme dhe unidireksionale.
React inkurajon një rrjedhë të dhënash nga lart-poshtë (unidireksionale) ku gjendja ndodhet në paraardhësin e përbashkët më të afërt që duhet ta kontrollojë atë. Një komponent prind mund të mbajë gjendjen dhe t'ua kalojë vlerat si prop te fëmijët, të cilët mund t'i renderojnë ose transformojnë ato, por nuk kanë nevojë të dinë nëse këto vlera kanë ardhur fillimisht nga gjendja, prop të tjera, apo janë koduar në mënyrë të ngurtë.
Kjo është arsyeja pse shpesh do të dëgjoni që gjendja është "lokale" ose "e kapsuluar". Vetëm komponenti që zotëron një pjesë të gjendjes mund ta ndryshojë atë, dhe çdo ndërfaqe përdoruesi e nxjerrë nga ajo gjendje rrjedh poshtë përmes prop-eve. Ju mund të kombinoni lirisht komponentët me gjendje dhe pa gjendje (të pastër), dhe nëse diçka është me gjendje konsiderohet një detaj zbatimi që mund të ndryshojë me kalimin e kohës.
Komponentët e klasës: gjendja dhe cikli jetësor sipas mënyrës së vjetër
Përpara Hooks, e vetmja mënyrë për të përdorur metodat e gjendjes dhe ciklit jetësor në React ishte me komponentët e klasës ES6. Edhe pse shumica e aplikacioneve moderne mbështeten në komponentët e funksionit, ju prapë do të shihni (dhe ndonjëherë do të mirëmbani) komponentët e klasës në shumë baza kodi, kështu që ia vlen të kuptoni se si funksionojnë ato.
Për të konvertuar një komponent funksioni si një të thjeshtë Clock në një klasë, ndiqni disa hapa mekanikë. Ju krijoni një klasë që zgjerohet React.Component, Shtoje nje render() metodë, zhvendos trupin e funksionit në render, zëvendëso props me this.props, dhe fshini funksionin origjinal. Për sa kohë që React vazhdon të renderojë <Clock /> në të njëjtën nyje DOM, ajo ripërdor një instancë të vetme të asaj klase.
Shtimi i gjendjes lokale në një klasë do të thotë përcaktimi i një konstruktori dhe caktimi i një fillestari this.state Objekt. Për shembull, mund të zhvendosni një date vlerën nga prop-et në gjendje duke shtuar një konstruktor që thërret super(props) dhe grupe this.state = { date: new Date() }, pastaj duke zëvendësuar çdo përdorim të this.props.date in render() me this.state.dateMbani mend se në komponentët e klasës duhet t'i caktoni vetëm direkt this.state brenda konstruktorit.
Metodat e ciklit jetësor janë metoda të klasës speciale që bëjnë thirrje React në pika specifike të jetëgjatësisë së një komponenti. Kur një komponent futet për herë të parë në DOM (montohet), React thërret componentDidMount()Kur hiqet (çmontohet), React thërret componentWillUnmount()Në shembullin klasik të orës që tik-tak, ju vendosni një kohëmatës në componentDidMount dhe pastroje atë brenda componentWillUnmount, duke ruajtur ID-në e kohëmatësit në this (për shembull this.timerId), dhe duke bërë thirrje this.setState() çdo sekondë për të përditësuar kohën.
Cikli jetësor tipik për atë orë duket kështu: React thërret konstruktorin për të inicializuar gjendjen, pastaj render() për të prodhuar DOM-in, atëherë componentDidMount() ku e filloni kohëmatësin. Sa herë që ndizet kohëmatësi, ju telefononi setState(), i cili vendos në radhë një përditësim dhe aktivizon render() me gjendjen e re. Pasi të hiqet komponenti, componentWillUnmount() Pastron kohëmatësin në mënyrë që të mos humbni burime.
Menaxhimi i saktë i gjendjes në klasa do të thotë gjithashtu respektimi i tre rregullave të rëndësishme rreth setState. Nuk duhet të pësosh mutacion this.state direkt, duhet të mbani mend se përditësimet mund të jenë asinkrone dhe të grupuara, dhe duhet të kuptoni se përditësimet bashkohen sipërfaqësisht (bashkohen vetëm çelësat e gjendjes së nivelit të lartë, jo objektet e ndërthurura thellë).
Përdorimi i saktë i gjendjes: mutacionet, përditësimet asinkrone dhe rrjedha e të dhënave
Një nga burimet më të mëdha të konfuzionit për fillestarët është se setState (dhe ekuivalenti i Hook) nuk e përditëson gjendjen menjëherë dhe nuk duhet t'i ndryshoni kurrë objektet e gjendjes në vend. React shpesh grumbullon disa përditësime së bashku për performancë, kështu që të dyja this.state Në klasat dhe variablat e gjendjes në Hooks mund të mos e pasqyrojnë gjendjen përfundimtare menjëherë pasi të planifikoni një përditësim.
Gjendje që ndryshon drejtpërdrejt, si të bësh this.state.count++ ose modifikimi i vetive të një objekti gjendjeje, anashkalon zbulimin e ndryshimeve të React dhe mund të shkaktojë që komponentët të mbeten të bllokuar në vlerat e vjetra. React pret që ju ta trajtoni çdo objekt në gjendje si vetëm për lexim. Në vend që të ndryshoni objektet ekzistuese, ju krijoni një objekt ose varg të ri me ndryshimet e dëshiruara dhe ia kaloni ato përditësuesit të gjendjes.
Meqenëse përditësimet e gjendjes mund të jenë asinkrone, duhet të jeni të kujdesshëm kur llogaritni gjendjen tjetër nga ajo e mëparshmja. Në klasa, diçka si this.setState({ count: this.state.count + 1 }) mund të jetë gabim nëse përditësime të shumta grumbullohen në grup. Zgjidhja është të përdoret forma funksionale: this.setState((prevState, props) => ({ count: prevState.count + 1 }))Kjo garanton që po punoni me pamjen më të fundit të gjendjes.
I njëjti model ekziston edhe me Hooks: mund ta thirrni përditësuesin me një funksion në vend të një vlere. Për shembull, setCount(prev => prev + 1) është mënyra më e sigurt për të rritur një numërues nëse vlera e re varet nga ajo e mëparshmja ose nëse përditësimet mund të ndodhin brenda kohëmatësve ose trajtuesve të ngjarjeve që ekzekutohen më vonë.
Edhe pse gjendja është "lokale", efekti i një ndryshimi të gjendjes gjithmonë përhapet poshtë pemës së komponentëve. Një ri-renderim prind i shkaktuar nga një përditësim i gjendjes do të ri-renderojë gjithashtu të gjithë fëmijët e tij si parazgjedhje. Ky rrjedhë të dhënash nga lart poshtë është thelbësore për modelin mendor të React: një burim i së vërtetës në krye, ndërfaqja e përdoruesit e nxjerrë prej tij poshtë.
Modern React: Grepa dhe komponentë funksioni
Që nga React 16.8, Hooks janë bërë mënyra standarde për të menaxhuar gjendjen dhe efektet anësore në komponentët e funksionit. Ato ju lejojnë të përdorni të njëjtat aftësi që kishin komponentët e klasës (dhe më shumë) pa shkruar klasa ose pa u marrë me to. this dhe metodat e ciklit të jetës në mënyrë eksplicite, apoyándose en el ekziston JavaScript modern.
Komponentët e funksionit tani janë stili i parazgjedhur në bazat e kodit React. Në vend të shkrimit class Example extends React.Component, ju përcaktoni një funksion të thjeshtë si function Example() { return <div />; }Kur keni nevojë për gjendje, efekte anësore ose referenca, ju "lidheni" me React nëpërmjet funksioneve si useState, useEffect useRefGrepat nuk mund të përdoren brenda klasave dhe duhet të respektojnë Rregullat e Grepave (thërijini gjithmonë ato në nivelin më të lartë të komponentit tuaj, kurrë në sythe ose kushte).
La useState Hook është mënyra më e thjeshtë për të shtuar gjendjen lokale në një komponent funksioni. Merr vlerën fillestare si argument dhe kthen një çift: vlerën e gjendjes aktuale dhe një përcaktues. Falë destruktimit të vargjeve zakonisht shkruani diçka si const = useState(0)React e ruan këtë gjendje midis ri-interpretimeve, që do të thotë se funksioni mund të thirret shumë herë, por vlera e gjendjes mbahet mend.
Ndryshe nga gjendja e klasës, vlera që mbani në useState nuk duhet të jetë domosdoshmërisht një objekt. Mund të ruani numra, vargje, vlera booleane, vargje ose objekte - çfarëdo që i përshtatet të dhënave. Nëse keni nevojë për vlera të shumëfishta të pavarura, mund të thirrni useState disa herë (për shembull, age, fruit, todosSi alternativë, mund të ruani një objekt të vetëm dhe të menaxhoni veti të shumta brenda tij, por duhet të respektoni rregullat e pandryshueshmërisë gjatë përditësimit.
Kur thirrni funksionin setter të kthyer nga useState, nuk po e ndryshoni vlerën në mënyrë sinkrone; po e vendosni në radhë një përditësim njësoj si me setState në klasa. Në renderimin tjetër, React i jep komponentit tuaj vlerën e re të gjendjes. Kjo është arsyeja pse leximi i gjendjes menjëherë pas thirrjes së përcaktuesit brenda të njëjtit funksion sinkron do t'ju japë prapë vlerën e vjetër.
Menaxhimi i objekteve dhe të dhënave të ndërthurura në gjendje
React ju lejon të vendosni çdo vlerë JavaScript në gjendjen state, duke përfshirë objektet dhe vargjet, por duhet t'i trajtoni ato si pamje të pandryshueshme. Vlerat primitive si numrat dhe vargjet nuk mund të mutohen gjithsesi, por objektet dhe vargjet teknikisht mund të mutohen - megjithatë, mutacioni i tyre shkel supozimet e React dhe mund të çojë në gabime delikate aty ku komponentët nuk përditësohen.
Konsideroni një objekt gjendjeje si { x: 0, y: 0 } që përfaqëson një pozicion treguesi. Nëse shkruani position.x = event.clientX direkt, ju keni ndryshuar objektin ekzistues. React nuk e ka idenë që vlera ka ndryshuar sepse nuk e keni thirrur kurrë setterin, kështu që nuk do të ri-renderohet dhe UI juaj mbetet i bllokuar. Qasja e saktë është setPosition({ x: event.clientX, y: event.clientY }), i cili krijon një objekt krejt të ri dhe i thotë React ta renderojë me të.
Mutacioni lokal i objekteve të krijuara rishtazi është krejtësisht në rregull. Për shembull, mund të ndërtoni një objekt të ri hap pas hapi: const next = { ...prev }; next.city = 'Paris'; sa kohë që next nuk ishte tashmë në gjendje. Mutacioni bëhet problem vetëm kur ndryshoni një objekt që tashmë është duke u përdorur në një pamje të gjendjes së mëparshme, sepse pjesë të tjera të aplikacionit tuaj mund të mbështeten ende në atë vlerë të vjetër.
Për të përditësuar vetëm një pjesë të një objekti duke ruajtur pjesën tjetër, zakonisht përdorni sintaksën e përhapjes së objektit. Për një objekt gjendjeje forme si p.sh. { firstName, lastName, email }, mund të trajtoni ndryshimet e të dhënave me diçka si setPerson({ ...person, : event.target.value })Kjo kopjon vetitë e vjetra, pastaj mbishkruan vetëm atë që ndryshoi. Përhapja është sipërfaqësore, kështu që objektet e ndërthurura kërkojnë më shumë kujdes.
Objektet e ndërthurura thellë mund të çojnë shpejt në kod të detajuar përditësimi, sepse duhet të krijoni kopje të reja përgjatë çdo niveli të shtegut që po ndryshoni. Për shembull, në qoftë se person.artwork.city ndryshime, do të bëje setPerson({ ...person, artwork: { ...person.artwork, city: 'London' } })Nën kapak, nuk ka "objekt të ndërthurur"; ka objekte të ndara që tregojnë nga njëri-tjetri, kështu që nëse shumë prindër tregojnë nga i njëjti objekt fëmijë dhe ju e mutoni atë, po ndryshoni të dhënat në më shumë se një vend në të njëjtën kohë.
Nëse e gjeni veten duke shkruar vazhdimisht përhapje të ndërthurura, mund të merrni në konsideratë rrafshimin e formës së gjendjes ose përdorimin e një biblioteke ndihmëse si Immer. Immer ju lejon të shkruani kod që duket mutativ (si p.sh. draft.artwork.city = 'London') ndërkohë që prodhon një kopje të re të pandryshueshme për ju prapa skenave. Në React, ju mund ta çiftoni Immer me Hooks nëpërmjet useImmer nga use-immer paketë.
Gjendja në praktikë: formularët, kohëmatësit dhe të dhënat e përdoruesit
Në aplikacionet e botës reale, rrallë menaxhohet gjendja vetëm për numëruesit; menaxhohen të dhënat e përdoruesit, përgjigjet e API-t dhe "modalitetet" e ndërfaqes së përdoruesit si ngarkimi, gabimi dhe suksesi. Ndryshimi kryesor i mentalitetit me React është se ju nuk e "manipuloni DOM-in" (për shembull, "çaktivizoni këtë buton"); në vend të kësaj, ju përshkruani se si duhet të duket UI për secilën gjendje dhe më pas përditësoni gjendjen.
Për shembull, një kuiz ose komponent formulari mund të gjurmojë një status gjendje që kalon midis 'typing', 'submitting' 'success'. JSX e çaktivizon me kusht butonin e dërgimit gjatë dërgimit dhe shfaq një mesazh suksesi pasi përgjigja të jetë e saktë. Nuk thirren kurrë metodat imperative DOM—React thjesht ri-interpretohet me gjendjen e re dhe rezultati vizual ndryshon.
Trajtimi i fushave të formularit është vendi ku shumë zhvillues hasin për herë të parë ndryshimin midis bashkimit të gjendjes së klasës dhe useState sjellje. Në një klasë, setState bashkon objektin që kaloni në objektin ekzistues të gjendjes, kështu që përditësimi i një fushe nuk i heq të tjerat. Me useState, përditësimet zëvendësojnë të gjithë vlerën: nëse gjendja juaj është një objekt dhe ju e thërrisni setState({ email: '...' }), çdo veti tjetër (si p.sh. password) zhduken nëse nuk i bashkoni manualisht.
Ky ndryshim i pengon njerëzit kur ata rifaktorizojnë nga variabla të shumëfishta të gjendjes primitive në një objekt të vetëm. Nëse ndryshoni nga const const në const dhe pastaj shkruani një gjenerik setForm({ : value }), do të përfundosh me një objekt gjendjeje që ka vetëm një fushë. Zgjidhja është të përhapësh objektin e mëparshëm: setForm({ ...form, : value }).
Në aplikacione më komplekse, shpesh nuk do të telefononi setState (Ose setSomething) direkt nga kudo. Mund ta centralizoni gjendjen duke përdorur biblioteka si Redux ose MobX, ose të përdorni useReducer Lidhës për makinat e gjendjes në nivel komponentësh. Në këto konfigurime, ju ende aplikoni të njëjtat parime të pandryshueshmërisë; e vetmja ndryshim është se ku dhe si kryhen përditësimet.
Ri-renderimet, performanca dhe kur të përdoret useRef
Çdo përditësim i gjendjes në React shkakton një ri-rendim të komponentit që zotëron gjendjen dhe, si parazgjedhje, të të gjithë komponentëve pasardhës të tij. Kjo është për shkak të dizajnit: ri-interpretimi është mënyra se si ndërfaqja juaj e përdoruesit qëndron e sinkronizuar me të dhënat aktuale. Por kjo gjithashtu do të thotë që vendosja e pamenduar e gjendjes mund të shkaktojë punë të panevojshme dhe ndërfaqe të përdoruesit të ngadaltë, veçanërisht kur komponentët fëmijë bëjnë llogaritje të kushtueshme ose renderojnë lista të mëdha.
Imagjinoni një aplikacion me një fushë hyrëse dhe një komponent të veçantë që tregon një listë të gjatë aftësish. Nëse komponenti prind zotëron si tekstin që përdoruesi po shkruan ashtu edhe vetë listën, atëherë çdo shtypje tastiere do ta ri-interpretojë të gjithë pemën, duke përfshirë listën e aftësive, edhe pse ajo listë nuk ka ndryshuar. Ky është një përpjekje e kotë.
Një mënyrë e thjeshtë për ta optimizuar këtë është duke i mbështjellë komponentët fëmijë në React.memo. React.memo është një komponent i rendit më të lartë që memorizon rezultatin e një komponenti funksioni: nëse prop-et e tij janë të njëjta midis renderimeve, React anashkalon ri-renderimin e tij. Pra, komponenti juaj i listës së aftësive, pasi të jetë i integruar React.memo, nuk do të ri-interpretohet me çdo shtypje të tastit—vetëm kur skills rekuizita ndryshon në të vërtetë (për shembull, kur shtoni një aftësi të re).
Jo të gjitha të dhënat "të ngjashme me shtetin" i përkasin useState; ndonjëherë useRef është mjeti më i mirë. La useRef Hook ju jep një objekt të ndryshueshëm me një current veti që vazhdon për gjithë jetëgjatësinë e komponentit, por përditësimi i saj e bën këtë nuk aktivizoni një ri-interpretim. Kjo e bën atë perfekt për ruajtjen e gjërave si ID-të e kohëmatësve, referencat e elementeve DOM ose numëruesit që dëshironi të gjurmoni, por nuk kanë nevojë të shfaqen në ndërfaqen e përdoruesit.
Një shembull i thjeshtë është një numërues i implementuar me useRef në vend të useState. Nëse e ruani numërimin në countRef.current dhe e rrit atë në një trajtues ngjarjesh, vlera e brendshme ndryshon, por JSX i shfaqur nuk do të përditësohet sepse React nuk e ri-renditi. Kjo ilustron ndryshimin thelbësor: useState është për vlerat që drejtojnë ndërfaqen e përdoruesit; useRef është për vlerat që dëshironi t'i ruani pa ndikuar në renderim.
Pandryshueshmëria dhe pse mutacioni i drejtpërdrejtë është një kurth
Një parim themelor në React është që përditësimet e gjendjes duhet të jenë të pandryshueshme. Kjo nuk do të thotë që nuk mund të ndryshosh kurrë asgjë; do të thotë që në vend që të modifikosh vlerat ekzistuese (veçanërisht objektet dhe vargjet), krijon të reja dhe i lë ato të vjetrat të qëndrojnë si pamje historike të ndërfaqes së përdoruesit tënd.
Gjendja që ndryshon drejtpërdrejt prish lidhjen midis modelit tuaj mendor dhe asaj që po bën React. Nëse bën diçka si state.count++ ose shtyjeni direkt në një varg gjendjesh, React nuk do ta dijë që diçka ka ndryshuar sepse nuk e keni thirrur kurrë funksionin përditësues. Pamja e brendshme e çastit që React përdor për të vendosur se kur të ri-interpretohet mbetet e njëjtë, ndërsa kodi juaj mendon se vlera ka ndryshuar. Kështu shfaqen gabime që "rregullohen vetë" kur ringarkoni.
Gjithashtu duhet të shmangni caktimin e një vlere gjendjeje për një ndryshore tjetër dhe më pas mutacionin e asaj ndryshoreje. Për shembull, duke bërë const newCount = count; newCount++; ende muton të njëjtën vlerë themelore për primitivët dhe për objektet, const copy = stateObj; nuk krijon fare një kopje - thjesht krijon një referencë tjetër për të njëjtin objekt. Kopjimi i duhur kërkon modele si { ...stateObj } për objekte ose për vargje.
Biblioteka si Redux, MobX (kur konfigurohen për pandryshueshmëri) ose Immer ekzistojnë pjesërisht për të zbatuar ose thjeshtuar modelet e pandryshueshme. Pavarësisht nëse përdorni Hooks të integruar të React ose një bibliotekë për menaxhimin e gjendjes, rregulli i artë vlen: mos e ndryshoni kurrë gjendjen ekzistuese nëse prisni që React ta kapë ndryshimin dhe ta riinterpretojë.
Përditësime asinkrone, grumbullim dhe gjendje e vjetëruar
Një detaj delikat, por thelbësor në lidhje me gjendjen e React është se përditësimet janë asinkrone dhe të planifikuara, nuk zbatohen menjëherë. Kur telefononi setState ose një setues grepi si setCountReact “e vendos në radhë” një ri-interpretim për një farë kohe në të ardhmen. Nuk e bllokon kodin tuaj që të përditësohet dhe ri-interpretohet menjëherë, gjë që i lejon React të bëjë disa përditësime në grup dhe të mbajë performancën të qetë.
Ky model planifikimi do të thotë që nuk mund të mbështeteni në gjendjen e leximit menjëherë pas thirrjes së përditësuesit brenda të njëjtit bllok sinkron. Vlera që merrni zakonisht do të jetë pamja e vjetër e çastit. Në vend të kësaj, duhet ta mendoni përditësuesin si një kërkesë: "herën tjetër që do të krijoni, përdorni këtë vlerë (ose këtë funksion transformimi)".
Kjo është veçanërisht e rëndësishme kur përditësoni gjendjen bazuar në vlerën e saj aktuale nga brenda mbylljeve si p.sh. setTimeout ose thirrje kthyese për abonime. Ato thirrje mbrapsht kapin çfarëdo gjendjeje që ishte në kohën kur u krijuan. Nëse atëherë e bën këtë setCount(count + 1) brenda një kohe të caktuar, count Ai për të cilin po referohesh mund të jetë i vjetëruar në kohën kur të ekzekutohet thirrja kthyese.
Ky fenomen njihet si "gjendje e ndenjur" ose "mbyllje të ndenjura". Për shembull, nëse keni një buton që, pas klikimit, thërret një funksion i cili cakton një kohëzgjatje dhe më pas rrit gjendjen pas një sekonde, klikime të shumta të shpejta mund të mos e rrisin gjendjen saktë. Çdo thirrje mbrapsht e kohëzgjatjes përdor funksionin e vjetër. count u kap kur ishte planifikuar skadimi i kohës.
Zgjidhja e fuqishme është të përdorni formën e përditësuesit funksional të përcaktuesit të gjendjes suaj. Në vend të setCount(count + 1) brenda kohës së caktuar, ti shkruan setCount(prevCount => prevCount + 1)Tani çdo thirrje mbrapsht merr vlerën më të fundit të mëparshme në kohën kur zbatohet përditësimi, jo atë që ndodhi të ishte në fushëveprim kur u krijua koha e pritjes. Kjo eliminon problemin e gjendjes së vjetëruar pa ndryshuar sjelljen e mbylljeve tuaja përndryshe.
Dokumentacioni i React gjithashtu thekson një detaj më pak të njohur: nëse përditësuesi juaj funksional nuk kthen asgjë (undefined), React do të anashkalojë ri-renditjen. Kjo do të thotë që funksionet tuaja të përditësimit duhet të kthejnë gjithmonë vlerën e gjendjes tjetër (ose të ripërdorin atë të mëparshmen) përveç nëse dëshironi në mënyrë të qartë të parandaloni një përditësim - diçka që rrallë dëshirohet me standardin useState Përdorimi.
Të kuptuarit e këtij kombinimi të planifikimit asinkron, grumbullimit dhe sjelljes së mbylljes është thelbësore për të shkruar logjikë të besueshme të gjendjes në aplikacionet që merren me skadimet e kohës, intervalet, abonimet ose ndërveprimet e shpejta të përdoruesve. Pasi të kuptoni që përcaktuesit e gjendjeve planifikojnë përditësimet në vend që t'i kryejnë ato menjëherë, gabimet që më parë dukeshin të rastësishme do të fillojnë të kenë kuptim.
Kur i bashkoni të gjitha këto ide - props vs state, ciklet jetësore të klasave vs Hooks, pandryshueshmëria, komponentët e kontrolluar, useRef Për vlerat jo-vizuale, memoizimin, përditësimet asinkrone dhe mbylljet e vjetra — ju përfundoni me një model të fuqishëm dhe të parashikueshëm për mënyrën se si evoluojnë ndërfaqet e përdoruesit të React me kalimin e kohës. Në vend që të mendoni në terma të ndryshimeve të domosdoshme të DOM-it, ju hartoni modele të gjendjes së qartë dhe e lini React-in të trajtojë ri-renditjen, gjë që i bën komponentët tuaj më të lehtë për t'u arsyetuar, testuar dhe zgjeruar ndërsa aplikacioni juaj rritet.
