You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Enfin, **renvoyez** le `listItems` depuis votre composant :
158
+
3. Enfin, **renvoyez** le `listItems` depuis votre composant :
159
159
160
160
```js
161
161
return<ul>{listItems}</ul>;
@@ -280,7 +280,7 @@ Warning: Each child in a list should have a unique "key" prop.
280
280
281
281
*(« Avertissement : chaque enfant d'une liste devrait avoir une prop "key" unique », NdT.)*
282
282
283
-
Vous devez fournir à chaque élément de tableau un`key` — une chaîne de caractères ou un nombre qui identifie de façon unique cet élément au sein du tableau :
283
+
Vous devez fournir à chaque élément de tableau une`key` — une chaîne de caractères ou un nombre qui identifie de façon unique cet élément au sein du tableau :
Que faire lorsque chaque élément de la liste doit produire non pas un, mais plusieurs nœuds DOM ?
386
386
387
-
La syntaxe concise de [Fragment `<>...</>`](/reference/react/Fragment) ne vous permet pas de passer une clé, vous devez donc soit les regrouper dans une `<div>`, soit utiliser la [syntaxe plus explicite `<Fragment>`](/reference/react/Fragment#rendering-a-list-of-fragments), certes un peu plus longue :
387
+
La syntaxe concise de [Fragment `<>...</>`](/reference/react/Fragment) ne vous permet pas de passer une clé, vous devez donc soit les regrouper dans une `<div>`, soit utiliser la [syntaxe plus explicite `<Fragment>`](/reference/react/Fragment#rendering-a-list-of-fragments), certes un peu plus longue, mais plus explicite :
Si vous êtes particulièrement attentif·ve, vous avez remarqué qu'avec deux appels à `filter`, on vérifie la profession de chaque personne deux fois. Vérifier une propriété reste très rapide, donc dans cet exemple ce n'est pas grave. Mais si votre logique était plus coûteuse que ça, vous pourriez remplacer les appels à `filter` par une boucle qui construit manuellement les tableaux en ne vérifiant chaque personne qu'une fois.
770
770
771
-
En fait, si `people` ne change jamais, vous pourriez carrément sortir ce code de votre composant. Du point de vue de React, tout ce qui compte, c'est que vous fournissiez un tableau de nœuds JSX au final. Il ne se préocuppe pas de la façon dont vous produisez ce tableau :
771
+
En fait, si `people` ne change jamais, vous pourriez carrément sortir ce code de votre composant. Du point de vue de React, tout ce qui compte, c'est que vous fournissiez un tableau de nœuds JSX au final. Il ne se préoccupe pas de la façon dont vous produisez ce tableau :
#### Des listes imbriquées dans un composant {/*nested-lists-in-one-component*/}
889
+
#### Des listes imbriquées {/*nested-lists-in-one-component*/}
890
890
891
891
Affichez une liste de recettes à partir du tableau fourni ! Pour chaque recette du tableau, affichez son nom dans un `<h2>` et listez ses ingrédients dans un `<ul>`.
892
892
@@ -1084,7 +1084,7 @@ export const recipes = [{
1084
1084
1085
1085
Dans ce code, `<Recipe {...recipe} key={recipe.id} />` est un raccourci syntaxique qui dit « passe toutes les propriétés de l'objet `recipe` comme props au composant `Recipe` ». Vous pourriez aussi écrire chaque prop explicitement : `<Recipe id={recipe.id} name={recipe.name} ingredients={recipe.ingredients} key={recipe.id} />`.
1086
1086
1087
-
**Remarquez que la `key` est spécifié sur le `<Recipe>` lui-même plutôt que sur la `<div>` racine renvoyée par `Recipe`.** C'est parce que `key` doit figurer directement dans le contexte du tableau environnant. Précédemment, vous aviez un tableau de `<div>` donc chacune d'elles nécessitait une `key`n mais maintenant vous avez un tableau de `<Recipe>`. En d'autres termes, quand vous extrayez un composant, n'oubliez pas de conserver la `key` hors du JSX que vous copiez-collez.
1087
+
**Remarquez que la `key` est spécifié sur le `<Recipe>` lui-même plutôt que sur la `<div>` racine renvoyée par `Recipe`.** C'est parce que `key` doit figurer directement dans le contexte du tableau environnant. Précédemment, vous aviez un tableau de `<div>` donc chacune d'elles nécessitait une `key` mais maintenant vous avez un tableau de `<Recipe>`. En d'autres termes, quand vous extrayez un composant, n'oubliez pas de conserver la `key` hors du JSX que vous copiez-collez.
1088
1088
1089
1089
</Solution>
1090
1090
@@ -1145,7 +1145,7 @@ hr {
1145
1145
1146
1146
</Sandpack>
1147
1147
1148
-
(C'est un des rares cas où l'utilisation de l'index comme clé serait acceptable parce que les lignes du poème ne changeront jamais.)
1148
+
(C'est un des rares cas où l'utilisation de l'index comme clé serait acceptable parce que les lignes du poème ne changeront jamais ni de nombre ni de place.)
1149
1149
1150
1150
<Hint>
1151
1151
@@ -1212,7 +1212,7 @@ hr {
1212
1212
1213
1213
Il ne suffit plus d'utiliser l'index de la ligne comme `key` car chaque séparateur et paragraphe font ici partie du même tableau. En revanche, vous pouvez leur donner à chacun une clé distincte en utilisant un suffixe, par exemple `key={i + '-text'}`.
1214
1214
1215
-
Une autre approche consisterait à produire une collection de Fragments qui contiennent `<hr />` et `<p>...</p>`. Attention cependant, la syntaxe concise `<>...</>` ne nous permettrait pas de passer des clés, nous devons donc écrire `<Fragment>` explicitement :
1215
+
Une autre approche consisterait à produire une collection de Fragments qui contiennent chacun `<hr />` et `<p>...</p>`. Attention cependant, la syntaxe concise `<>...</>` ne nous permettrait pas de passer des clés, nous devons donc écrire `<Fragment>` explicitement :
0 commit comments