{"id":3540,"date":"2021-07-24T08:53:39","date_gmt":"2021-07-24T08:53:39","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/react-keys-yes-you-need-them-but-why-exactly\/"},"modified":"2026-04-24T11:30:22","modified_gmt":"2026-04-24T11:30:22","slug":"reaksjonsnokler-ja-du-trenger-dem-men-hvorfor-akkurat","status":"publish","type":"post","link":"https:\/\/thecodest.co\/nb\/blog\/react-keys-yes-you-need-them-but-why-exactly\/","title":{"rendered":"React-n\u00f8kler, ja! Du trenger dem, men hvorfor egentlig?"},"content":{"rendered":"

Det er ogs\u00e5 \u00e9n ting til du m\u00e5 huske p\u00e5, og det er React<\/a> N\u00f8kkel<\/strong> attributtet, m\u00e5 hvert element i den gjengitte listen ha det. Dette konseptet er noe av det f\u00f8rste alle front-end utvikler<\/a> l\u00e6rer om React<\/strong> i begynnelsen av reisen. La oss n\u00e5 grave litt dypere for \u00e5 finne ut hvorfor det er slik, og n\u00e5r vi kan ta noen snarveier.<\/p>\n

Hvorfor trenger vi denne n\u00f8kkelegenskapen?<\/h2>\n

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

    \n
  1. To forskjellige typer elementer vil aldri v\u00e6re like - s\u00e5 gj\u00f8r dem om igjen.<\/li>\n
  2. Utviklere kan manuelt bidra til \u00e5 optimalisere prosessen ved hjelp av n\u00f8kkelattributter, slik at elementene kan lokaliseres og sammenlignes raskere, selv om rekkef\u00f8lgen p\u00e5 dem er endret.<\/li>\n<\/ol>\n

    Basert p\u00e5 dette kan vi konkludere med at hver React-n\u00f8kkel<\/strong> skal ogs\u00e5 v\u00e6re unike (innenfor listen av elementer, ikke globalt), og stabile (skal ikke endres). Men hva kan skje n\u00e5r de ikke er det?<\/p>\n

    Unikhet, stabilitet og matriseindeks<\/h2>\n

    Som vi har nevnt tidligere, React-taster<\/strong> b\u00f8r v\u00e6re stabil og unik. Den enkleste m\u00e5ten \u00e5 oppn\u00e5 dette p\u00e5 er \u00e5 bruke en unik ID (for eksempel fra en database) og sende den til hvert element n\u00e5r du tilordner en matrise. Men hva med situasjoner der vi ikke har en ID, et navn eller andre unike identifikatorer \u00e5 sende til hvert element? Hvis vi ikke oppgir noe som n\u00f8kkel, er det enkelt, React<\/strong> vil som standard ta den gjeldende matriseindeksen (siden den er unik innenfor listen) for \u00e5 h\u00e5ndtere den for oss<\/a>men det vil ogs\u00e5 gi oss en fin feilmelding i konsollen:<\/p>\n

    \"\"<\/p>\n

    Hvorfor er det slik? Svaret er at matriseindeksen ikke er stabil. Hvis rekkef\u00f8lgen p\u00e5 elementene endres, vil hver av n\u00f8klene endres, og vi har et problem. Hvis React<\/strong> oppst\u00e5r en situasjon der rekkef\u00f8lgen i en liste med elementer ble endret, vil den fortsatt pr\u00f8ve \u00e5 sammenligne dem etter n\u00f8klene, noe som betyr at hver sammenligning vil ende opp med \u00e5 bygge en komponent p\u00e5 nytt, og som et resultat vil hele listen bli bygget opp p\u00e5 nytt fra bunnen av. I tillegg kan vi st\u00f8te p\u00e5 noen uventede problemer, som oppdateringer av komponenttilstanden for elementer som ukontrollerte innganger og andre magiske problemer som er vanskelige \u00e5 feils\u00f8ke.<\/p>\n

    Unntak<\/h2>\n

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

    Et alternativ til en datasettbasert n\u00f8kkel<\/h2>\n

    La oss si at ingen av de ovennevnte er et alternativ for oss. Vi m\u00e5 for eksempel vise en liste med elementer basert p\u00e5 en matrise med strenger som kan dupliseres, men som ogs\u00e5 kan omorganiseres. I dette tilfellet kan vi ikke bruke noen av strengene fordi de ikke er unike (dette kan ogs\u00e5 for\u00e5rsake noen magiske feil), og matriseindeksen er ikke god nok fordi vi vil endre rekkef\u00f8lgen p\u00e5 elementene. Det siste vi kan stole p\u00e5 i situasjoner som dette, er bruken av noen eksterne identifikatorer. Husk at det m\u00e5 v\u00e6re stabilt, s\u00e5 vi kan ikke bare bruke Math.random(). Det finnes noen NPM-pakker som vi kan bruke i slike tilfeller, for eksempel \"uuid\"<\/a> pakken. Slike verkt\u00f8y kan hjelpe oss med \u00e5 holde listen\u00f8klene v\u00e5re stabile og unike, selv n\u00e5r vi ikke finner de riktige identifikatorene i data<\/a> sett. Vi b\u00f8r vurdere \u00e5 bruke database-ID og matriseindeks (hvis mulig) f\u00f8rst, for \u00e5 minimere antall pakker som brukes av v\u00e5r prosjekt<\/a>.<\/p>\n

    For \u00e5 oppsummere<\/h2>\n