React-nøkler, ja! Du trenger dem, men hvorfor egentlig?

Det er også én ting til du må huske på, og det er React Nøkkel attributtet, må hvert element i den gjengitte listen ha det. Dette konseptet er noe av det første alle frontend-utviklere lærer om React i begynnelsen av reisen. La oss nå grave litt dypere for å finne ut hvorfor det er slik, og når vi kan ta noen snarveier.

Hvorfor trenger vi denne nøkkelegenskapen?

Det enkleste svaret her ville være "for å optimalisere re-rendering", men et mer fullstendig svar må i det minste nevne konseptet med React Avstemming. Dette er prosessen med å finne ut hvordan du oppdaterer brukergrensesnittet på den mest effektive måten. For å gjøre det raskt, React må avgjøre hvilke deler av elementtreet som skal oppdateres, og hvilke som ikke skal det. Problemet er at det kan være mange elementer i DOM-en, og det er ganske kostbart å sammenligne hvert av dem for å avgjøre hvilket som skal oppdateres. For å optimalisere dette, React implementerer diffing-algoritmen, som er basert på to forutsetninger:

1. To forskjellige typer elementer vil aldri være like - så gjør dem om igjen.
2. Utviklere kan manuelt bidra til å optimalisere prosessen ved hjelp av nøkkelattributter, slik at elementene kan lokaliseres og sammenlignes raskere, selv om rekkefølgen på dem er endret.

Basert på dette kan vi konkludere med at hver React-nøkkel skal også være unike (innenfor listen av elementer, ikke globalt), og stabile (skal ikke endres). Men hva kan skje når de ikke er det?

Unikhet, stabilitet og matriseindeks

Som vi har nevnt tidligere, React-taster bør være stabil og unik. Den enkleste måten å oppnå dette på er å bruke en unik ID (for eksempel fra en database) og sende den til hvert element når du tilordner en matrise. Men hva med situasjoner der vi ikke har en ID, et navn eller andre unike identifikatorer å sende til hvert element? Hvis vi ikke oppgir noe som nøkkel, er det enkelt, React vil som standard ta den gjeldende matriseindeksen (siden den er unik i listen) for å håndtere det for oss, men den vil også gi oss en fin feilmelding i konsollen:

Hvorfor er det slik? Svaret er at matriseindeksen ikke er stabil. Hvis rekkefølgen på elementene endres, vil hver av nøklene endres, og vi har et problem. Hvis React oppstår en situasjon der rekkefølgen i en liste med elementer ble endret, vil den fortsatt prøve å sammenligne dem etter nøklene, noe som betyr at hver sammenligning vil ende opp med å bygge en komponent på nytt, og som et resultat vil hele listen bli bygget opp på nytt fra bunnen av. I tillegg kan vi støte på noen uventede problemer, som oppdateringer av komponenttilstanden for elementer som ukontrollerte innganger og andre magiske problemer som er vanskelige å feilsøke.

Unntak

La oss gå tilbake til matriseindeksen. Hvis du bruker den som en React-nøkkel kan være så problematisk, hvorfor React vil bruke det som standard? Finnes det noen brukstilfeller der det er greit å gjøre det? Svaret er ja, det er i statiske lister. Hvis du er sikker på at en liste du gjengir aldri vil endre rekkefølgen, er det trygt å bruke matriseindeks, men husk at hvis du har unike identifikatorer, er det fortsatt bedre å bruke dem i stedet. Du kan også legge merke til at hvis du bruker indekser som nøkler, vil React feilmeldingen forsvinner, samtidig som noen av de eksterne linterne viser en feil eller advarsel. Dette skyldes at eksplisitt bruk av indekser som nøkler anses som en dårlig praksis, og noen lintere kan behandle det som en feil, mens React selv anser det som en "utviklerne vet hva de gjør"-situasjon - så ikke gjør det med mindre du virkelig vet hva du gjør. Noen eksempler på når det kan være greit å bruke dette unntaket, er en nedtrekksmeny med en statisk liste med knapper eller visning av en liste med elementer med firmaets adresseinformasjon.

Et alternativ til en datasettbasert nøkkel

La oss si at ingen av de ovennevnte er et alternativ for oss. Vi må for eksempel vise en liste med elementer basert på en matrise med strenger som kan dupliseres, men som også kan omorganiseres. I dette tilfellet kan vi ikke bruke noen av strengene fordi de ikke er unike (dette kan også forårsake noen magiske feil), og matriseindeksen er ikke god nok fordi vi vil endre rekkefølgen på elementene. Det siste vi kan stole på i situasjoner som dette, er bruken av noen eksterne identifikatorer. Husk at det må være stabilt, så vi kan ikke bare bruke Math.random(). Det finnes noen NPM-pakker som vi kan bruke i slike tilfeller, for eksempel "uuid" pakken. Slike verktøy kan hjelpe oss med å holde listenøklene våre stabile og unike, selv når vi ikke finner de riktige identifikatorene i datasettet vårt. Vi bør vurdere å bruke database-ID og matriseindeks (hvis mulig) først, for å minimere antall pakker som brukes av vår prosjekt.

For å oppsummere

• Hvert element på listen over React elementer bør ha et unikt, stabilt nøkkelattributt,
• React-taster brukes til å øke hastigheten på Avstemmingsprosessen og unngå unødvendig ombygging av elementer på listene,
• Den beste kilden for nøkler er unik ID for dataregistrering (for eksempel fra databasen),
• Du kan bruke matriseindeksen som nøkkel, men bare for en statisk liste hvis rekkefølge ikke endres,
• Hvis det ikke finnes noen annen måte å få stabile og unike nøkler på, kan du vurdere å bruke eksterne ID-leverandører, for eksempel "uuid"-pakken.

Les mer om dette:

Derfor bør du (sannsynligvis) bruke Typescript

Hvordan unngår man å drepe et prosjekt med dårlig kodingspraksis?

Strategier for datahenting i NextJS