React Lyklar, já! Þú þarft þá, en af hverju nákvæmlega?

Það er líka eitt fleira sem þú þarft að muna um og það er React Lykill Eiginleiki, hvert atriði í birtu listanum verður að hafa hann. Þetta hugtak er eitt af fyrstu hlutunum sem hver front-end þróunaraðili kynnist React Í upphafi ferðar þeirra. Nú skulum við kafa aðeins dýpra til að kanna hvers vegna þetta er svona og hvenær við getum tekið nokkra stuttleiðir.

Af hverju þurfum við þessa lykilatriði?

Einfaldasta svarið hér væri “að hámarka endurteikningar”, en hið fullkomnara svar þarf að minnsta kosti að nefna hugtakið React Samræming. Þetta er ferlið við að komast að því hvernig á að uppfæra notendaviðmótið á sem skilvirkastan hátt. Til að gera það hratt, React þarf að ákveða hvaða hlutar í tré þáttanna þurfa að vera uppfærðir og hvaða ekki. Málið er að það geta verið margir þættir í DOM-inu og það er nokkuð kostnaðarsamt að bera saman hvern og einn þeirra til að ákveða hvaða eigi að uppfæra. Til að hagræða þessu, React Innleiðir diffing-algorítmann sem byggir á tveimur forsendum:

1. Tvö mismunandi gerðir af þáttum verða aldrei eins – endurskipuleggðu þær.
2. Forritarar geta handvirkt aðstoðað við að hagræða þessu ferli með lykilatriðum, svo að þættirnir, jafnvel þó röð þeirra hafi breyst, megi staðfæra og bera saman hraðar.

Á grundvelli þess getum við dregið þá ályktun að hver React lykill Ætti einnig að vera einstakt (innan lista yfir þætti, ekki alþjóðlega) og stöðugt (ekki breytast). En hvað gæti gerst þegar þau eru ekki þannig?

Einstæðni, stöðugleiki og fylkisvísitala

Eins og við nefndum áður, React lyklar Á að vera stöðugt og einstakt. Einfaldasta leiðin til að ná þessu er að nota einstakt auðkenni (til dæmis úr gagnagrunni) og senda það til hvers þáttar þegar fylki er kortlagt, auðvelt. En hvað með aðstæður þegar við höfum hvorki auðkenni, nafn né önnur einstök auðkenni til að senda til hvers þáttar? Jæja, ef við sendum ekkert sem lykil, React mun taka núverandi fylkisvísitölu sem sjálfgefið gildi (þar sem hún er einstök innan þess lista) til að meðhöndla það fyrir okkur, en það mun einnig gefa okkur fallega villutilkynningu í console-inu:

Af hverju er það svona? Svarið er að fylki-vísitalan er ekki stöðug. Ef röð atriða breytist, munu allir lyklarnir breytast og við eigum í vandræðum. Ef React Þegar forritið lendir í að röð þáttanna í lista hafi breyst mun það samt reyna að bera þá saman með lykla, sem þýðir að hver samanburður endar í því að endurbyggja einingu og afleiðingin er sú að allur listinn verður endurbyggður frá grunni. Auk þess getum við lent í óvæntum vandamálum, eins og uppfærslum á ástandi eininga fyrir þætti eins og óstýrðum innsláttum og öðrum töfrandi, erfiðum villuleitavandamálum.

Undantekningar

Skoðum aftur fylkisvísitöluna. Ef hún er notuð sem React lykill getur verið svo vandamál, af hverju React Mun það vera notað sem sjálfgefið? Er til einhver notkunartilvik þar sem það er í lagi að gera það? Svarið er já, notkunartilvik þess er fastar listar. Ef þú ert viss um að listinn sem þú birtir muni aldrei breyta röð sinni, er öruggt að nota fylkisvísitölu, en mundu að ef þú hefur einstök auðkenni er samt betra að nota þau í staðinn. Þú getur einnig tekið eftir því að það að senda vísitölur sem lykla mun gera React villuboð hverfur, á sama tíma og kveikir í sumum ytri linterum til að birta villu eða viðvörun. Þetta er vegna þess að bein notkun vísitala sem lykla er talin slæm vinnubrögð og sumir linterar gætu flokkað það sem villu, á meðan React sjálft telur það vera “þróunaraðilar vita hvað þeir eru að gera” aðstæður – svo gerðu það ekki nema þú vitir virkilega hvað þú ert að gera. Nokkur dæmi um þegar það getur verið í lagi að nota þessa undantekningu væru fellivalmynd með föstum lista af hnöppum eða birta lista yfir atriði með heimilisfangi fyrirtækisins.

Valkostur við lykil byggðan á gagnasafni

Segjum sem svo að ekkert af ofangreindu sé valkostur fyrir okkur. Til dæmis þurfum við að birta lista yfir þætti byggðan á strengjarað sem má afrita, en einnig má raða upp á nýtt. Í þessu tilfelli getum við ekki notað neinn af strengjunum því þeir eru ekki einstakir (þetta getur líka valdið töfravillum), og fylki-vísitalan dugar ekki þar sem við munum breyta röðinni á þáttunum. Síðasta úrræðið sem við getum treyst á í svona aðstæðum er að nota einhverjar ytri auðkenningar. Mundu að þær verða að vera stöðugar, svo við getum ekki bara notað Math.random(). Það eru nokkur NPM-pakkí sem við getum notað í slíkum tilvikum, til dæmis the “uuid” pakki. Verkfæri eins og þetta geta hjálpað okkur að halda lykla listans stöðugum og einstökum, jafnvel þegar við finnum ekki viðeigandi auðkenni innan okkar gögn set. Við ættum fyrst að íhuga að nota gagnagrunnsauðkenni og fylkisvísitölu (ef mögulegt er), til að lágmarka fjölda pakka sem notuð eru af okkar verkefni.

Til að ljúka þessu

• Hvert atriði á listanum yfir React Þættir skulu hafa einstakt, stöðugt lykilatriði,
• React lyklar eru notuð til að flýta fyrir Fá samræmi í ferli og forðast óþarfa endurbyggingu þátta á listunum,
• Besti uppspretta fyrir lykla er einstakt auðkenni úr gagnainnslætti (til dæmis úr gagnagrunninum),
• Þú getur notað fylkisvísitölu sem lykil, en aðeins fyrir kyrrstæða fylkislista þar sem röðin mun ekki breytast.,
• Ef engin önnur leið er til að fá stöðugar og einstakar lyklar, íhugaðu að nota einhverja utanaðkomandi auðkenningaraðila, til dæmis “uuid”-pakkann.

Lesa meira:

Af hverju þú ættir (líklega) að nota TypeScript

Hvernig á ekki að drepa verkefni með slæmum forritunarvenjum?

Stefnur við gagnaleit í NextJS