Choisir une bonne `key` (stable, unique et prédictible)

Apprenez les critères essentiels pour choisir une bonne prop `key` en React : stabilité, unicité et prédictibilité. Evitez les pièges courants et optimisez vos rendus de listes.

Les critères d'une clé efficace : stabilité avant tout

Nous avons établi l'importance des clés, mais toutes les clés ne se valent pas. Pour que React puisse exploiter pleinement les avantages des clés, celles-ci doivent respecter plusieurs critères fondamentaux. Le plus important est la **stabilité**. Une clé est considérée comme stable si elle ne change pas pour un même élément logique d'une liste entre différents rendus. Si la clé d'un élément change, React interprétera cela comme la suppression de l'ancien élément et l'ajout d'un nouveau, même si les données sous-jacentes sont identiques. Cela entraîne la perte de l'état local du composant (comme le contenu d'un ``) et la recréation inutile du noeud DOM, annulant ainsi les bénéfices de la réconciliation.

Imaginez une clé générée aléatoirement à chaque rendu (`key={Math.random()}`). A chaque mise à jour, tous les éléments auraient de nouvelles clés, forçant React à démonter et remonter l'intégralité de la liste. C'est précisément ce que les clés sont censées éviter ! La clé doit être intrinsèquement liée à l'identité de l'élément qu'elle représente.

Unicité parmi les frères : éviter les conflits d'identité

Le deuxième critère essentiel est l'**unicité**. Chaque clé doit être unique parmi ses frères et soeurs directs dans la liste. React utilise ces clés pour distinguer les éléments au même niveau hiérarchique. Si deux éléments dans la même liste partagent la même clé, React ne pourra pas les différencier correctement lors de la réconciliation. Cela conduira à des comportements imprévisibles, des mises à jour incorrectes et, heureusement, à un avertissement clair dans la console de développement vous signalant le problème.

Il est important de noter que l'unicité n'est requise qu'au sein d'une même liste (un même appel à `map()`). Deux listes différentes dans des parties distinctes de votre application peuvent tout à fait réutiliser les mêmes valeurs de clés sans conflit, car elles n'appartiennent pas au même ensemble de frères et soeurs.

Prédictibilité : Lier la clé à la donnée

Enfin, une bonne clé est généralement **prédictible**. Idéalement, elle doit être directement dérivée de la donnée qu'elle représente. L'approche la plus fiable et recommandée est d'utiliser un identifiant unique (ID) provenant de vos données. Si vous affichez une liste d'utilisateurs récupérée d'une base de données, l'ID unique de chaque utilisateur (`user.id`) est le candidat parfait pour la clé.

Si vos données n'ont pas d'ID stable et unique, vous devrez peut-être en construire un. Parfois, une combinaison de plusieurs champs peut former une clé unique et stable. Dans des cas plus rares, on pourrait envisager de hasher une partie du contenu de l'élément pour générer une clé, mais cela peut avoir des implications sur les performances et doit être fait avec prudence. L'objectif est d'avoir une clé qui identifie l'élément de manière cohérente à travers le temps et les rendus.

La source idéale : les identifiants uniques de vos données

La meilleure source pour vos clés est presque toujours un identifiant unique et stable qui provient directement de vos données. Ces ID sont conçus pour être uniques et ne changent généralement pas au cours de la vie d'un objet de données.

function ProductList({ products }) {
  // 'products' est un tableau d'objets, chacun avec un 'id' unique de la BDD
  // Exemple: [{ id: 'prod-123', name: 'Widget A' }, { id: 'prod-456', name: 'Gadget B' }]
  
  return (
    
      {products.map((product) => (
        // Utilisation directe de l'ID produit comme clé : STABLE et UNIQUE
        
          {product.name}
        
      ))}
    
  );
}

Cette approche est la plus robuste car elle garantit la stabilité et l'unicité requises par React, tout en liant directement l'identité de l'élément rendu à l'identité de la donnée source. C'est la stratégie à privilégier chaque fois que possible.

Le cas particulier de l'index du tableau : à utiliser avec précaution

Il est techniquement possible d'utiliser l'index d'un élément dans le tableau comme clé (`map((item, index) =>

...)`). Cependant, c'est souvent une **mauvaise pratique** et la source de bugs subtils, car l'index n'est *pas stable*. Si des éléments sont ajoutés, supprimés ou réordonnés dans la liste, l'index d'un élément logique donné changera, violant le critère de stabilité.

Utiliser l'index comme clé est uniquement acceptable dans des conditions très spécifiques et cumulatives :

1. La liste et ses éléments sont **statiques** : ils ne seront jamais réordonnés ou filtrés.

2. Les éléments de la liste n'ont **pas d'ID stable** propre.

3. La liste ne sera **jamais modifiée** (pas d'ajout ni de suppression au début ou au milieu ; l'ajout à la fin *peut* être acceptable).

Si l'une de ces conditions n'est pas remplie, l'utilisation de l'index comme clé peut entraîner des problèmes de performance et des erreurs de rendu d'état. Dans la grande majorité des cas, il est préférable de trouver ou de générer un véritable identifiant stable et unique lié à la donnée elle-même.

// Exemple où l'index PEUT être acceptable (liste statique sans ID)
const menuItems = ['Accueil', 'Profil', 'Paramètres'];

function StaticMenu() {
  return (
    
      {menuItems.map((item, index) => (
        {item}
      ))}
    
  );
}

// Exemple où l'index est DANGEREUX (liste dynamique)
function DynamicList({ items }) {
  // Si 'items' est filtré ou réordonné, utiliser l'index ici causera des problèmes !
  return (
    
      {items.map((item, index) => (
        // MAUVAISE PRATIQUE si la liste change
        
      ))}
    
  );
}

◄ Précédent Suivant ►

く