{"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":"klucze-reaktywne-tak-sa-potrzebne-ale-po-co-dokladnie","status":"publish","type":"post","link":"https:\/\/thecodest.co\/pl\/blog\/react-keys-yes-you-need-them-but-why-exactly\/","title":{"rendered":"Klucze React, tak! Potrzebujesz ich, ale dlaczego dok\u0142adnie?"},"content":{"rendered":"

Jest jeszcze jedna rzecz, o kt\u00f3rej nale\u017cy pami\u0119ta\u0107, a mianowicie React<\/a> Klucz<\/strong> ka\u017cdy element renderowanej listy musi go posiada\u0107. Ta koncepcja jest jedn\u0105 z pierwszych rzeczy, kt\u00f3re ka\u017cdy front-end deweloper<\/a> dowiaduje si\u0119 o React<\/strong> na pocz\u0105tku ich podr\u00f3\u017cy. Przyjrzyjmy si\u0119 teraz nieco g\u0142\u0119biej, aby dowiedzie\u0107 si\u0119, dlaczego tak jest i kiedy mo\u017cemy p\u00f3j\u015b\u0107 na skr\u00f3ty.<\/p>\n

Dlaczego potrzebujemy tego kluczowego atrybutu?<\/h2>\n

Najprostsz\u0105 odpowiedzi\u0105 by\u0142oby \"zoptymalizowa\u0107 ponowne renderowanie\", ale bardziej kompletna odpowied\u017a musi przynajmniej wspomnie\u0107 o koncepcji React Uzgodnienie<\/strong>. Jest to proces polegaj\u0105cy na ustaleniu, jak zaktualizowa\u0107 interfejs u\u017cytkownika w najbardziej efektywny spos\u00f3b. Aby zrobi\u0107 to szybko, React<\/strong> musi zdecydowa\u0107, kt\u00f3re cz\u0119\u015bci drzewa element\u00f3w musz\u0105 zosta\u0107 zaktualizowane, a kt\u00f3re nie. Problem polega na tym, \u017ce w DOM mo\u017ce znajdowa\u0107 si\u0119 wiele element\u00f3w, a por\u00f3wnywanie ka\u017cdego z nich w celu podj\u0119cia decyzji, kt\u00f3ry z nich powinien zosta\u0107 zaktualizowany, jest do\u015b\u0107 kosztowne. Aby to zoptymalizowa\u0107, React<\/strong> implementuje algorytm diffing, kt\u00f3ry opiera si\u0119 na dw\u00f3ch za\u0142o\u017ceniach:<\/p>\n

    \n
  1. Dwa r\u00f3\u017cne typy element\u00f3w nigdy nie b\u0119d\u0105 takie same - wi\u0119c nale\u017cy je ponownie wyrenderowa\u0107.<\/li>\n
  2. Programi\u015bci mog\u0105 r\u0119cznie pom\u00f3c zoptymalizowa\u0107 ten proces za pomoc\u0105 kluczowych atrybut\u00f3w, dzi\u0119ki czemu elementy, nawet je\u015bli ich kolejno\u015b\u0107 uleg\u0142a zmianie, mog\u0105 by\u0107 szybciej lokalizowane i por\u00f3wnywane.<\/li>\n<\/ol>\n

    Na tej podstawie mo\u017cemy stwierdzi\u0107, \u017ce ka\u017cdy Klucz React<\/strong> powinny by\u0107 r\u00f3wnie\u017c unikalne (w obr\u0119bie listy element\u00f3w, nie globalnie) i stabilne (nie powinny si\u0119 zmienia\u0107). Ale co mo\u017ce si\u0119 sta\u0107, gdy nie s\u0105 one takie same?<\/p>\n

    Wyj\u0105tkowo\u015b\u0107, stabilno\u015b\u0107 i indeks tablicy<\/h2>\n

    Jak wspomnieli\u015bmy wcze\u015bniej, Klawisze React<\/strong> powinien by\u0107 stabilny i unikalny. Najprostszym sposobem na osi\u0105gni\u0119cie tego jest u\u017cycie unikalnego identyfikatora (na przyk\u0142ad z bazy danych) i przekazanie go do ka\u017cdego elementu podczas mapowania tablicy. Ale co z sytuacjami, w kt\u00f3rych nie mamy ID, nazwy lub innych unikalnych identyfikator\u00f3w do przekazania ka\u017cdemu elementowi? C\u00f3\u017c, je\u015bli nie przeka\u017cemy niczego jako klucza, React<\/strong> domy\u015blnie przyjmie bie\u017c\u0105cy indeks tablicy (poniewa\u017c jest on unikalny w ramach tej listy), aby obs\u0142u\u017cy\u0107 go dla my<\/a>, ale da nam r\u00f3wnie\u017c \u0142adny komunikat o b\u0142\u0119dzie w konsoli:<\/p>\n

    \"\"<\/p>\n

    Dlaczego tak si\u0119 dzieje? Odpowied\u017a brzmi: indeks tablicy nie jest stabilny. Je\u015bli zmieni si\u0119 kolejno\u015b\u0107 element\u00f3w, ka\u017cdy z kluczy ulegnie zmianie i mamy problem. Je\u015bli React<\/strong> napotka sytuacj\u0119, w kt\u00f3rej kolejno\u015b\u0107 na li\u015bcie element\u00f3w zosta\u0142a zmieniona, nadal b\u0119dzie pr\u00f3bowa\u0142 por\u00f3wna\u0107 je wed\u0142ug kluczy, co oznacza, \u017ce ka\u017cde por\u00f3wnanie zako\u0144czy si\u0119 ponownym zbudowaniem komponentu, a w rezultacie ca\u0142a lista zostanie odbudowana od zera. Ponadto mo\u017cemy napotka\u0107 pewne nieoczekiwane problemy, takie jak aktualizacje stanu komponent\u00f3w dla element\u00f3w takich jak niekontrolowane wej\u015bcia i inne magiczne, trudne do debugowania problemy.<\/p>\n

    Wyj\u0105tki<\/h2>\n

    Wr\u00f3\u0107my do indeksu tablicy. Je\u015bli u\u017cywamy go jako Klucz React<\/strong> mo\u017ce by\u0107 tak problematyczne, dlaczego React<\/strong> b\u0119dzie go u\u017cywa\u0107 domy\u015blnie? Czy jest jaki\u015b przypadek u\u017cycia, w kt\u00f3rym mo\u017cna to zrobi\u0107? Odpowied\u017a brzmi: tak, przypadkiem u\u017cycia s\u0105 listy statyczne. Je\u015bli jeste\u015b pewien, \u017ce renderowana lista nigdy nie zmieni swojej kolejno\u015bci, mo\u017cesz bezpiecznie u\u017cy\u0107 indeksu tablicy, ale pami\u0119taj, \u017ce je\u015bli masz jakie\u015b unikalne identyfikatory, nadal lepiej jest ich u\u017cy\u0107. Mo\u017cna r\u00f3wnie\u017c zauwa\u017cy\u0107, \u017ce przekazanie indeks\u00f3w jako kluczy spowoduje, \u017ce funkcja React<\/strong> komunikat o b\u0142\u0119dzie znika, jednocze\u015bnie powoduj\u0105c wy\u015bwietlenie b\u0142\u0119du lub ostrze\u017cenia przez niekt\u00f3re z zewn\u0119trznych linter\u00f3w. Wynika to z faktu, \u017ce jawne u\u017cycie indeks\u00f3w jako kluczy jest uwa\u017cane za z\u0142\u0105 praktyk\u0119, a niekt\u00f3re lintery mog\u0105 traktowa\u0107 to jako b\u0142\u0105d, podczas gdy React<\/strong> sama uwa\u017ca to za sytuacj\u0119 \"deweloperzy wiedz\u0105, co robi\u0105\" - wi\u0119c nie r\u00f3b tego, chyba \u017ce naprawd\u0119 wiesz, co robisz. Kilka przyk\u0142ad\u00f3w sytuacji, w kt\u00f3rych mo\u017cna u\u017cy\u0107 tego wyj\u0105tku, to lista rozwijana ze statyczn\u0105 list\u0105 przycisk\u00f3w lub wy\u015bwietlanie listy element\u00f3w z informacjami o adresie firmy.<\/p>\n

    Alternatywa dla klucza opartego na zestawie danych<\/h2>\n

    Za\u0142\u00f3\u017cmy, \u017ce \u017cadna z powy\u017cszych opcji nie jest dla nas dost\u0119pna. Na przyk\u0142ad, musimy wy\u015bwietli\u0107 list\u0119 element\u00f3w opart\u0105 na tablicy ci\u0105g\u00f3w, kt\u00f3re mog\u0105 by\u0107 duplikowane, ale mog\u0105 by\u0107 r\u00f3wnie\u017c uporz\u0105dkowane. W tym przypadku nie mo\u017cemy u\u017cy\u0107 \u017cadnego z ci\u0105g\u00f3w, poniewa\u017c nie s\u0105 one unikalne (mo\u017ce to r\u00f3wnie\u017c powodowa\u0107 pewne magiczne b\u0142\u0119dy), a indeks tablicy nie jest wystarczaj\u0105co dobry, poniewa\u017c zmienimy kolejno\u015b\u0107 element\u00f3w. Ostatni\u0105 rzecz\u0105, na kt\u00f3rej mo\u017cemy polega\u0107 w takich sytuacjach, jest u\u017cycie zewn\u0119trznych identyfikator\u00f3w. Pami\u0119tajmy, \u017ce musz\u0105 one by\u0107 stabilne, wi\u0119c nie mo\u017cemy po prostu u\u017cy\u0107 Math.random(). Istniej\u0105 pewne pakiety NPM, kt\u00f3rych mo\u017cemy u\u017cy\u0107 w takich przypadkach, na przyk\u0142ad \"uuid\"<\/a> package. Narz\u0119dzia takie jak to mog\u0105 pom\u00f3c nam zachowa\u0107 stabilne i unikalne klucze listy, nawet je\u015bli nie mo\u017cemy znale\u017a\u0107 odpowiednich identyfikator\u00f3w w naszym pakiecie. dane<\/a> set. Powinni\u015bmy najpierw rozwa\u017cy\u0107 u\u017cycie identyfikatora bazy danych i indeksu tablicy (je\u015bli to mo\u017cliwe), aby zminimalizowa\u0107 liczb\u0119 pakiet\u00f3w u\u017cywanych przez nasz\u0105 baz\u0119 danych. projekt<\/a>.<\/p>\n

    Podsumowuj\u0105c<\/h2>\n