{"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":"reagir-aux-cles-oui-vous-en-avez-besoin-mais-pourquoi-exactement","status":"publish","type":"post","link":"https:\/\/thecodest.co\/fr\/blog\/react-keys-yes-you-need-them-but-why-exactly\/","title":{"rendered":"Cl\u00e9s React, oui ! Vous en avez besoin, mais pourquoi exactement ?"},"content":{"rendered":"

Il y a encore une chose dont vous devez vous souvenir, et c'est la React<\/a> Cl\u00e9<\/strong> chaque \u00e9l\u00e9ment de la liste rendue doit l'avoir. Ce concept est l'une des premi\u00e8res choses que tout front-end d\u00e9veloppeur<\/a> s'informe sur React<\/strong> au d\u00e9but de leur parcours. Nous allons maintenant nous pencher un peu plus sur les raisons de cette situation et sur les moments o\u00f9 il est possible de prendre des raccourcis.<\/p>\n

Pourquoi avons-nous besoin de cet attribut cl\u00e9 ?<\/h2>\n

La r\u00e9ponse la plus simple serait \"d'optimiser les re-renders\", mais la r\u00e9ponse la plus compl\u00e8te doit au moins mentionner le concept de React Rapprochement<\/strong>. Il s'agit de d\u00e9terminer comment mettre \u00e0 jour l'interface utilisateur de la mani\u00e8re la plus efficace possible. Pour y parvenir rapidement, React<\/strong> doit d\u00e9cider quelles parties de l'arbre des \u00e9l\u00e9ments doivent \u00eatre mises \u00e0 jour et lesquelles ne doivent pas l'\u00eatre. Le probl\u00e8me est qu'il peut y avoir beaucoup d'\u00e9l\u00e9ments dans le DOM et que comparer chacun d'entre eux pour d\u00e9cider lequel doit \u00eatre mis \u00e0 jour est assez co\u00fbteux. Pour optimiser ce processus, React<\/strong> met en \u0153uvre l'algorithme diffing qui repose sur deux hypoth\u00e8ses :<\/p>\n

    \n
  1. Deux types d'\u00e9l\u00e9ments diff\u00e9rents ne seront jamais identiques.<\/li>\n
  2. Les d\u00e9veloppeurs peuvent contribuer manuellement \u00e0 l'optimisation de ce processus par le biais d'attributs cl\u00e9s, de sorte que les \u00e9l\u00e9ments, m\u00eame si leur ordre a chang\u00e9, peuvent \u00eatre localis\u00e9s et compar\u00e9s plus rapidement.<\/li>\n<\/ol>\n

    Sur cette base, nous pouvons conclure que chaque Cl\u00e9 React<\/strong> doivent \u00e9galement \u00eatre uniques (dans la liste des \u00e9l\u00e9ments, pas globalement) et stables (ils ne doivent pas changer). Mais que se passe-t-il lorsqu'ils ne le sont pas ?<\/p>\n

    Unicit\u00e9, stabilit\u00e9 et indice de tableau<\/h2>\n

    Comme nous l'avons d\u00e9j\u00e0 mentionn\u00e9, Cl\u00e9s React<\/strong> doit \u00eatre stable et unique. Le moyen le plus simple d'y parvenir est d'utiliser un identifiant unique (provenant par exemple d'une base de donn\u00e9es) et de le transmettre \u00e0 chaque \u00e9l\u00e9ment lors du mappage d'un tableau, ce qui est facile. Mais qu'en est-il des situations o\u00f9 nous n'avons pas d'ID, de nom ou d'autres identifiants uniques \u00e0 passer \u00e0 chaque \u00e9l\u00e9ment ? Eh bien, si nous ne passons rien comme cl\u00e9, React<\/strong> prendra par d\u00e9faut l'index du tableau courant (puisqu'il est unique dans cette liste) pour le g\u00e9rer pour nous<\/a>mais cela nous donnera aussi un beau message d'erreur dans la console :<\/p>\n

    \"\"<\/p>\n

    Pourquoi en est-il ainsi ? La r\u00e9ponse est que l'index du tableau n'est pas stable. Si l'ordre des \u00e9l\u00e9ments change, chacune des cl\u00e9s changera et nous aurons un probl\u00e8me. Si l'ordre des \u00e9l\u00e9ments change, chacune des cl\u00e9s changera et nous aurons un probl\u00e8me. React<\/strong> Dans une situation o\u00f9 l'ordre d'une liste d'\u00e9l\u00e9ments a \u00e9t\u00e9 modifi\u00e9, il essaiera toujours de les comparer par les cl\u00e9s, ce qui signifie que chaque comparaison aboutira \u00e0 la reconstruction d'un composant et que, par cons\u00e9quent, la liste enti\u00e8re sera reconstruite \u00e0 partir de z\u00e9ro. En outre, nous pouvons rencontrer des probl\u00e8mes inattendus, comme des mises \u00e0 jour de l'\u00e9tat des composants pour des \u00e9l\u00e9ments tels que des entr\u00e9es non contr\u00f4l\u00e9es et d'autres probl\u00e8mes magiques difficiles \u00e0 d\u00e9boguer.<\/p>\n

    Exceptions<\/h2>\n

    Revenons \u00e0 l'index du tableau. Si on l'utilise comme Cl\u00e9 React<\/strong> peut \u00eatre si probl\u00e9matique, pourquoi React<\/strong> l'utilisera par d\u00e9faut ? Existe-t-il un cas d'utilisation pour lequel il est acceptable de le faire ? La r\u00e9ponse est oui, le cas d'utilisation est celui des listes statiques. Si vous \u00eates s\u00fbr que la liste que vous rendez ne changera jamais d'ordre, vous pouvez utiliser l'index de tableau, mais rappelez-vous que si vous avez des identifiants uniques, il est pr\u00e9f\u00e9rable de les utiliser \u00e0 la place. Vous pouvez \u00e9galement remarquer que le fait de passer des index en tant que cl\u00e9s rendra la fonction React<\/strong> dispara\u00eet, tout en d\u00e9clenchant simultan\u00e9ment l'affichage d'une erreur ou d'un avertissement par certains linters externes. Cela est d\u00fb au fait que l'utilisation explicite d'index comme cl\u00e9s est consid\u00e9r\u00e9e comme une mauvaise pratique et que certains linters peuvent la traiter comme une erreur, tandis que React<\/strong> consid\u00e8re qu'il s'agit d'une situation o\u00f9 \"les d\u00e9veloppeurs savent ce qu'ils font\" - ne le faites donc pas \u00e0 moins que vous ne sachiez vraiment ce que vous faites. Quelques exemples de cas o\u00f9 il est possible d'utiliser cette exception : un menu d\u00e9roulant avec une liste statique de boutons ou l'affichage d'une liste d'\u00e9l\u00e9ments avec l'adresse de votre entreprise.<\/p>\n

    Une alternative \u00e0 la cl\u00e9 bas\u00e9e sur les ensembles de donn\u00e9es<\/h2>\n

    Supposons qu'aucune des options ci-dessus ne soit envisageable. Par exemple, nous devons afficher une liste d'\u00e9l\u00e9ments bas\u00e9e sur un tableau de cha\u00eenes de caract\u00e8res qui peut \u00eatre dupliqu\u00e9, mais aussi r\u00e9ordonn\u00e9. Dans ce cas, nous ne pouvons utiliser aucune des cha\u00eenes parce qu'elles ne sont pas uniques (ce qui peut \u00e9galement provoquer des bogues magiques), et l'index du tableau n'est pas suffisant parce que nous allons changer l'ordre des \u00e9l\u00e9ments. La derni\u00e8re chose sur laquelle nous pouvons compter dans ce genre de situation est l'utilisation d'identifiants externes. Rappelez-vous qu'ils doivent \u00eatre stables, nous ne pouvons donc pas nous contenter de Math.random(). Il existe des paquets NPM que nous pouvons utiliser dans de tels cas, par exemple le paquet \"uuid\"<\/a> paquet. De tels outils peuvent nous aider \u00e0 maintenir la stabilit\u00e9 et l'unicit\u00e9 de nos cl\u00e9s de liste, m\u00eame lorsque nous ne pouvons pas trouver d'identifiants appropri\u00e9s dans notre donn\u00e9es<\/a> set. Nous devrions envisager d'utiliser d'abord l'ID de la base de donn\u00e9es et l'index du tableau (si possible), afin de minimiser le nombre de paquets utilis\u00e9s par notre projet<\/a>.<\/p>\n

    En r\u00e9sum\u00e9<\/h2>\n