Translation of 'Choosing the state structure' page #513
Conversation
Size changes📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
tdd
added
Pending Review
There was a problem hiding this comment.
Salut @KohdeAvekLeQ ! Tu vas bien ?
J'ai enfin le temps de faire la revue… et je ne comprends pas ce que tu m'as fait. 😳
Tes deux premières PR étaient plutôt soignées, y'avait peu de coquilles, y'avait un vrai travail de formulation, c'était top.
Là, c'est pire que du Google Translate. Y'a des tas d'oublis et de coquilles (pas de relecture ?), de contre-sens, c'est du mot-à-mot sans contexte, y'a des choix de trads à l'opposé de tout le corpus déjà établi…
C'est un très gros morceau (≈2800 lignes pour ≈350 lignes/paragraphes modifés, on a une douzaine de pages de ce calibre dans la doc) et j'ai la nette impression que tu n'as au final pas eu le temps que tu voulais pour t'en occuper, et surtout pas les horaires, car ça sent fort la fatigue, surtout par rapport à tes deux premières livraisons.
Le souci, c'est que du coup mon propre boulot, qui est déjà bien plus grand en revue qu'en traduction directe, est ici multiplié vu le volume de retouches nécessaires.
Du coup là je m'arrête après la ligne 100 et je te fais ce premier retour.
Que fait-on ? Je n'ai pas du tout envie de jeter ton travail, il t'a manifestement pris beaucoup de temps quand même. Mais sur ce coup précis, c'est juste trop peu fini pour qu'il y ait du sens à ce que je travaille en mode revue sur le matériau brut.
Il y a deux voies évidentes possibles, et sûrement d'autres auxquelles je ne pense pas tout de suite, mais tu auras peut-être des alternatives intéressantes à me proposer.
- Tu as le temps et la motivation pour faire une grosse repasse avec un œil frais sur ta livraison (notamment coquilles, typographie, fluidité des phrases, sémantique correcte, etc.) : super ! passe-la en Draft, fais quelques commits d'ici la fin du mois pour nettoyer tout ça, et remets-la en statut fini en me faisant signe, je referai la revue.
- T'as plus le temps et / ou l'envie : j'aurai davantage intérêt à refaire une trad intégrale moi-même, d'un seul tenant. Pour ce genre de volume, il me faut environ 4 heures à pleine balle, revue visuelle finale comprise.
- Une autre voie…? Des idées ?
Désolé de te mettre devant ce choix, c'est désagréable et n'y vois surtout pas du mépris ou de la rage, on n'est pas du tout là-dessus. Tu as passé du temps et des efforts, bénévolement, pour nous aider sur déjà 2 autres trads et sur ce mammouth, et c'est hyper cool, merci, vraiment. Mais parfois, y'a un loupé, on vise à côté, on est fatigué, on n'est pas concentré…
Hâte de voir ce que tu proposes pour la suite.
Bien à toi,
| * Quand utiliser état unique ou multiple | ||
| * Les choses à éviter en organisant l’état | ||
| * Résoudre des problèmes connus avec la structure de l’état |
There was a problem hiding this comment.
| * Quand utiliser état unique ou multiple | |
| * Les choses à éviter en organisant l’état | |
| * Résoudre des problèmes connus avec la structure de l’état | |
| * Quand utiliser une vs. plusieurs variables d'état | |
| * Les pièges à éviter en organisant l’état | |
| * Comment résoudre les problèmes courants de structure de l’état |
Ouah, on n'est qu'au début, et tu me fais des trads très très discutables. J'espère que la suite va mieux, parce qu'on parle quand même de 300 titres, paragraphes et lignes… 😳
|
|
||
| </YouWillLearn> | ||
|
|
||
| ## Principles for structuring state {/*principles-for-structuring-state*/} | ||
| ## Les principes pour structurer l’état {/*principles-for-structuring-state*/} |
There was a problem hiding this comment.
| ## Les principes pour structurer l’état {/*principles-for-structuring-state*/} | |
| ## Principes de structuration d’état {/*principles-for-structuring-state*/} |
|
|
||
| When you write a component that holds some state, you'll have to make choices about how many state variables to use and what the shape of their data should be. While it's possible to write correct programs even with a suboptimal state structure, there are a few principles that can guide you to make better choices: | ||
| Quand vous créez un comoposant qui contient des états, vous devrez faire des choix sur le nombre de variables d’état à utiliser et quelle sera la forme de leurs données. Même si il est possible d’écrire des programmes corrects avec une structure d’état peu optimale, il y a quelques principes qui peuvent vous guider pour faire des meilleurs choix : |
There was a problem hiding this comment.
| Quand vous créez un comoposant qui contient des états, vous devrez faire des choix sur le nombre de variables d’état à utiliser et quelle sera la forme de leurs données. Même si il est possible d’écrire des programmes corrects avec une structure d’état peu optimale, il y a quelques principes qui peuvent vous guider pour faire des meilleurs choix : | |
| Quand vous créez un composant qui contient des états, vous devez faire des choix sur le nombre de variables d’état à utiliser et la forme de leurs données. Même s'il est possible d’écrire des programmes corrects avec une structure d’état sous-optimale, il y a quelques principes qui peuvent vous guider pour faire de meilleurs choix : |
| 1. **Les états de groupe.** Si vous actualisez tout le temps deux variables d’état ou plus à la fois, essayez de les fusionner en une seule variable d’état. | ||
| 2. **Evitez les contradictions dans l’état.** Quand l’état est stucturé d’une manière où plusieurs parties d’état peuvent être contradictoires et en "désaccord" entre elles, des erreurs peuvent s’induire. Essayez d’éviter cela. | ||
| 3. **Evitez les états redondants.** Si vous pouvez calculer des informations à partir des props du composant ou d’une de ses variables d'état pendant l’affichage, vous ne devriez pas mettre ces informations dans un état du composant. | ||
| 4. **Evitez la duplication d’états.** Quand la même donnée est dupliquée entre plusieurs variables d’état ou dans des objets imbriqués, c’est difficile de les garder synchronisées. Réduisez la duplication quand vous le pouvez. | ||
| 5. **Evitez les états fortement imbriqués** Un état fortement hiérarchisé n’est pas très pratique à actualiser. Quand c’est possible, priorisez une stucture d'état plate. |
There was a problem hiding this comment.
| 1. **Les états de groupe.** Si vous actualisez tout le temps deux variables d’état ou plus à la fois, essayez de les fusionner en une seule variable d’état. | |
| 2. **Evitez les contradictions dans l’état.** Quand l’état est stucturé d’une manière où plusieurs parties d’état peuvent être contradictoires et en "désaccord" entre elles, des erreurs peuvent s’induire. Essayez d’éviter cela. | |
| 3. **Evitez les états redondants.** Si vous pouvez calculer des informations à partir des props du composant ou d’une de ses variables d'état pendant l’affichage, vous ne devriez pas mettre ces informations dans un état du composant. | |
| 4. **Evitez la duplication d’états.** Quand la même donnée est dupliquée entre plusieurs variables d’état ou dans des objets imbriqués, c’est difficile de les garder synchronisées. Réduisez la duplication quand vous le pouvez. | |
| 5. **Evitez les états fortement imbriqués** Un état fortement hiérarchisé n’est pas très pratique à actualiser. Quand c’est possible, priorisez une stucture d'état plate. | |
| 1. **Regroupez les états associés.** Si vous mettez tout le temps à jour plusieurs variables d’état à la fois, essayez de les fusionner en une seule variable d’état. | |
| 2. **Évitez les contradictions dans l’état.** Quand l’état est structuré de sorte que plusieurs parties d’état puissent être contradictoires, des erreurs peuvent survenir. Essayez d’éviter ça. | |
| 3. **Évitez les états redondants.** Si vous pouvez calculer des informations à partir des props du composant ou de ses variables d'état existantes pendant le rendu, vous ne devriez pas mettre ces informations dans un état du composant. | |
| 4. **Évitez la duplication d’états.** Quand la même donnée est dupliquée entre plusieurs variables d’état ou dans des objets imbriqués, il est difficile de les garder synchronisées. Réduisez la duplication quand vous le pouvez. | |
| 5. **Évitez les états fortement imbriqués.** Un état fortement hiérarchisé n’est pas très pratique à mettre à jour. Quand c’est possible, priorisez une structure d'état plate. |
Un gros glissement sémantique, et ce "actualiser" qui est plutôt connoté "rafraîchir" (genre depuis un serveur), là où toutes les trads existantes disent "mettre à jour".
Par ailleurs, beaucoup de coquilles ; tu n'as pas fait une relecture avant de finaliser ta PR ?
|
|
||
| ## Group related state {/*group-related-state*/} | ||
| ## Les états de groupe {/*group-related-state*/} |
There was a problem hiding this comment.
| ## Les états de groupe {/*group-related-state*/} | |
| ## Regrouper les états associés {/*group-related-state*/} |
|
|
||
| You might sometimes be unsure between using a single or multiple state variables. | ||
| Vous hésitez peut-être quelques fois entre utiliser une variable d’état simple ou multiple. |
There was a problem hiding this comment.
| Vous hésitez peut-être quelques fois entre utiliser une variable d’état simple ou multiple. | |
| Vous hésitez peut-être parfois entre utiliser une ou plusieurs variables d’état. |
|
|
||
| ```js | ||
| const [position, setPosition] = useState({ x: 0, y: 0 }); | ||
| ``` | ||
|
|
||
| Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable.** Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot: | ||
| Techniquement, vous pouvez ces deux approches. Mais **si deux variables changent d’état toujours ensemble, une bonne idée serait de les unir en une seule variable d’état.** Vous n’oublirez pas par la suite de toujours les garder synchronisées, comme dans cet exemple où les mouvements du curseur actualisent les 2 coordonnées du point rouge. |
There was a problem hiding this comment.
| Techniquement, vous pouvez ces deux approches. Mais **si deux variables changent d’état toujours ensemble, une bonne idée serait de les unir en une seule variable d’état.** Vous n’oublirez pas par la suite de toujours les garder synchronisées, comme dans cet exemple où les mouvements du curseur actualisent les 2 coordonnées du point rouge. | |
| Techniquement, les deux approches sont possibles. Mais **si deux variables d’état changent toujours ensemble, ce serait une bonne idée de les réunir en une seule variable d’état.** Vous n’oublierez ainsi pas ensuite de les garder synchronisées, comme dans cet exemple où les mouvements du curseur mettent à jour les deux coordonnées du point rouge. |
| @@ -93,17 +93,17 @@ body { margin: 0; padding: 0; height: 250px; } | |||
|
|
|||
| </Sandpack> | |||
|
|
|||
| Another case where you'll group data into an object or an array is when you don't know how many pieces of state you'll need. For example, it's helpful when you have a form where the user can add custom fields. | |||
| Un autre cas où vous pouvez regrouper des données dans un objet ou une liste est lorsque vous ne savez pas combien de parties d'état vous aurez besoin. Par exemple, c’est utile quand vous avez un questionnaire dans lequel l’utilisateur peut ajouter des champs personnalisés. | |||
There was a problem hiding this comment.
| Un autre cas où vous pouvez regrouper des données dans un objet ou une liste est lorsque vous ne savez pas combien de parties d'état vous aurez besoin. Par exemple, c’est utile quand vous avez un questionnaire dans lequel l’utilisateur peut ajouter des champs personnalisés. | |
| Une autre situation dans laquelle vous pouvez regrouper des données dans un objet ou une liste, c'est lorsque vous ne savez pas à l'avance de combien d'éléments d'état vous aurez besoin. Par exemple, c’est utile pour un formulaire dans lequel l’utilisateur peut ajouter des champs personnalisés. |
|
|
||
| <Pitfall> | ||
|
|
||
| If your state variable is an object, remember that [you can't update only one field in it](/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`. | ||
| Si votre variable d’état est un objet, souvenez vous que [vous ne pouvez actualiser qu’un seul de ses champs](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car om n’y aurait plus du tout la variable `y` ! À la place, si vous vouliez définir `x` tout seul, vous feriez soit `setPosition({ ...position, x: 100 })`, soit la séparation en deux variables d’état et `setX(100)`. |
There was a problem hiding this comment.
| Si votre variable d’état est un objet, souvenez vous que [vous ne pouvez actualiser qu’un seul de ses champs](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car om n’y aurait plus du tout la variable `y` ! À la place, si vous vouliez définir `x` tout seul, vous feriez soit `setPosition({ ...position, x: 100 })`, soit la séparation en deux variables d’état et `setX(100)`. | |
| Si votre variable d’état est un objet, souvenez-vous que [vous ne pouvez pas mettre à jour qu’un seul champ](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car il n’y aurait plus du tout la variable `y` ! Au lieu de ça, si vous vouliez définir `x` tout seul, soit vous feriez `setPosition({ ...position, x: 100 })`, soit vous découperiez l'information en deux variables d’état et `setX(100)`. |
tdd
added
Reviewing
|
Salut ! |
Merci pour ton engagement, bon courage à toi ! 💪 |
|
Voilà, il y avait beaucoup de choses à corriger, j'espère n'avoir rien oublié, merci pour les reviews. |
|
Hello !
OK je vais tenter de refaire une passe cet après-midi, sur les 100 premières lignes déjà, on verra ensuite. Tu as traité les points remontés au global, ou juste sur le début ? Car tu sembles avoir été très vite ! o_O
…On Tue, Jul 18, 2023, at 10:57, Kohdé wrote:
Voilà, il y avait beaucoup de choses à corriger, j'espère n'avoir rien oublié, merci pour les reviews.
—
Reply to this email directly, view it on GitHub <#513 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAA5KE76PPJ5YU34FSDOPLXQZFW3ANCNFSM6AAAAAA2HDPFTI>.
You are receiving this because you were assigned.Message ID: ***@***.***>
--
Christophe Porteneuve
***@***.***
|
|
Normalement j'ai tout repassé, j'avais commencé hier mais pas répondu ici |
|
OK comme t'as tout repassé je la remets Ready for Review. |
There was a problem hiding this comment.
Salut @KohdeAvekLeQ !
Avant toute chose, merci pour tout ce boulot ! C'est super cool de nous filer un coup de main.
Écoute c'est vachement mieux, même si j'ai fait pas mal de retours sur cette partie. J'ai revu jusqu'aux Défis, je fais les Défis dans une revue à part dans pas longtemps (GitHub couine assez comme ça dès qu'on dépasse genre 30 commentaires… pfff…)
Tu auras des correctifs à propager toi-même sur plusieurs reprises au fil de la page, je te l'ai indiqué chaque fois que nécessaire.
Beau boulot !
Avant de traiter les retours, lis bien TOUT ce message, notamment les consignes d'intégration optimale des retours par lot(s)
Tout est fait sous forme de Suggestions GitHub, il te suffit à chaque suggestion que tu approuves de
cliquer le bouton d'ajout au lot de modifs à committer (pas de commit direct !), et sur la fin de créer le commit groupé. (ce mode de regroupement en un seul commit est à favoriser absolument, mais tu devras aller dans l'onglet Files changed pour y accéder, il n'est pas utilisable dans l’onglet Conversation)
Si certaines appellent discussion, n'hésite pas, tu réponds, on en parle, on avance ensemble 🤝
Quand tout sera bouclé côté code, je ferai une repasse visuelle finale en local avant de fusionner. J'y recalerai si besoin les usual suspects : espaces insécables avant les ponctuations doubles, et apostrophes françaises.
Encore mille mercis, j'ai hâte de voir cette PR finalisée et dans main !
|
|
||
| The goal behind these principles is to *make state easy to update without introducing mistakes*. Removing redundant and duplicate data from state helps ensure that all its pieces stay in sync. This is similar to how a database engineer might want to ["normalize" the database structure](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) to reduce the chance of bugs. To paraphrase Albert Einstein, **"Make your state as simple as it can be--but no simpler."** | ||
| Ces principes visent à *rendre l’état simple à actualiser sans créer d’erreurs*. Retirer les données redondantes et dupliquées de l’état aide à s’assurer que toutes ses parties restent synchronisées. C’est un peu comme un ingénieur de bases de données qui souhaite ["normaliser" la structure de la base de données](https://learn.microsoft.com/fr-fr/office/troubleshoot/access/database-normalization-description) pour réduire les risques de bugs. Pour paraphraser Albert Einstein : **« Faites que votre état soit le plus simple possible — mais pas plus simple. »** |
There was a problem hiding this comment.
| Ces principes visent à *rendre l’état simple à actualiser sans créer d’erreurs*. Retirer les données redondantes et dupliquées de l’état aide à s’assurer que toutes ses parties restent synchronisées. C’est un peu comme un ingénieur de bases de données qui souhaite ["normaliser" la structure de la base de données](https://learn.microsoft.com/fr-fr/office/troubleshoot/access/database-normalization-description) pour réduire les risques de bugs. Pour paraphraser Albert Einstein : **« Faites que votre état soit le plus simple possible — mais pas plus simple. »** | |
| Ces principes visent à *rendre l’état simple à actualiser sans créer d’erreurs*. Retirer les données redondantes et dupliquées de l’état aide à s’assurer que toutes ses parties restent synchronisées. C’est un peu comme un ingénieur de bases de données qui souhaite [« normaliser » la structure de la base de données](https://learn.microsoft.com/fr-fr/office/troubleshoot/access/database-normalization-description) pour réduire les risques de bugs. Pour paraphraser Albert Einstein : **« Faites que votre état soit le plus simple possible — mais pas plus simple. »** |
|
|
||
| ```js | ||
| const [position, setPosition] = useState({ x: 0, y: 0 }); | ||
| ``` | ||
|
|
||
| Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable.** Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot: | ||
| Techniquement, les deux approches sont possibles. Mais **si deux variables d’état changent toujours ensemble, ce serait une bonne idée de les réunir en une seule variable d’état.** Vous n’oublierez ainsi pas ensuite de les garder synchronisées, comme dans cet exemple où les mouvements du curseur mettent à jour les deux coordonnées du point rouge. |
There was a problem hiding this comment.
| Techniquement, les deux approches sont possibles. Mais **si deux variables d’état changent toujours ensemble, ce serait une bonne idée de les réunir en une seule variable d’état.** Vous n’oublierez ainsi pas ensuite de les garder synchronisées, comme dans cet exemple où les mouvements du curseur mettent à jour les deux coordonnées du point rouge. | |
| Techniquement, les deux approches sont possibles. Mais **si deux variables d’état changent toujours ensemble, ce serait une bonne idée de les réunir en une seule variable d’état**. Vous n’oublierez ainsi pas ensuite de les garder synchronisées, comme dans cet exemple où les mouvements du curseur mettent à jour les deux coordonnées du point rouge. |
|
|
||
| <Pitfall> | ||
|
|
||
| If your state variable is an object, remember that [you can't update only one field in it](/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`. | ||
| Si votre variable d’état est un objet, souvenez-vous que [vous ne pouvez pas mettre à jour qu’un seul champ](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car il n’y aurait plus du tout la variable `y` ! Au lieu de ça, si vous vouliez définir `x` tout seul, soit vous feriez `setPosition({ ...position, x: 100 })`, soit vous découperiez l'information en deux variables d’état et `setX(100)`. |
There was a problem hiding this comment.
| Si votre variable d’état est un objet, souvenez-vous que [vous ne pouvez pas mettre à jour qu’un seul champ](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car il n’y aurait plus du tout la variable `y` ! Au lieu de ça, si vous vouliez définir `x` tout seul, soit vous feriez `setPosition({ ...position, x: 100 })`, soit vous découperiez l'information en deux variables d’état et `setX(100)`. | |
| Si votre variable d’état est un objet, souvenez-vous que [vous ne pouvez pas mettre à jour qu’un seul champ](/learn/updating-objects-in-state) sans explicitement copier les autres champs. Par exemple, vous ne pouvez pas faire `setPosition({ x: 100 })` dans l’exemple ci-dessus car il n’y aurait plus du tout la propriété `y` ! Au lieu de ça, si vous vouliez définir `x` tout seul, soit vous feriez `setPosition({ ...position, x: 100 })`, soit vous découperiez l'information en deux variables d’état et feriez `setX(100)`. |
| } | ||
|
|
||
| return ( | ||
| <form onSubmit={handleSubmit}> | ||
| <p>How was your stay at The Prancing Pony?</p> | ||
| <p>Comment était votre séjour au Poney Vagabond ?</p> |
There was a problem hiding this comment.
| <p>Comment était votre séjour au Poney Vagabond ?</p> | |
| <p>Comment était votre séjour au Poney Fringant ?</p> |
| @@ -1838,25 +1841,25 @@ button { margin: 10px; } | |||
|
|
|||
| </DeepDive> | |||
|
|
|||
| Sometimes, you can also reduce state nesting by moving some of the nested state into the child components. This works well for ephemeral UI state that doesn't need to be stored, like whether an item is hovered. | |||
| Parfois, vous pouvez aussi réduire l’imbrication des états en déplaçant une partie de l’état imbriqué dans les composants enfants. Cela fonctionne bien pour les états éphémères de l’UI qui n’ont pas besoin d’être stockés, comme le fait de savoir si un élément est survolé. | |||
There was a problem hiding this comment.
| Parfois, vous pouvez aussi réduire l’imbrication des états en déplaçant une partie de l’état imbriqué dans les composants enfants. Cela fonctionne bien pour les états éphémères de l’UI qui n’ont pas besoin d’être stockés, comme le fait de savoir si un élément est survolé. | |
| Parfois, vous pouvez aussi réduire l’imbrication des états en déplaçant une partie de l’état imbriqué dans les composants enfants. C'est bien adapté aux états éphémères de l’UI qui n’ont pas besoin d’être stockés, comme le fait de savoir si un élément est survolé. |
| * For UI patterns like selection, keep ID or index in state instead of the object itself. | ||
| * If updating deeply nested state is complicated, try flattening it. | ||
| * Si deux variables d’état sont toujours mises à jour ensemble, envisagez de les fusionner en une seule. | ||
| * Choississez soigneusement vos variables d’état pour éviter de créer des "états" impossibles. |
There was a problem hiding this comment.
| * Choississez soigneusement vos variables d’état pour éviter de créer des "états" impossibles. | |
| * Choisissez soigneusement vos variables d’état pour éviter de créer des états « impossibles ». |
| * Structurez votre état de manière à réduire les risques d’erreur lors de sa mise à jour. | ||
| * Evitez les états dupliqués et redondants afin de ne pas avoir à les synchroniser. | ||
| * Ne mettez pas de props *dans* un état à moins que vous ne vouliez spécifiquement empêcher les mises à jour. | ||
| * Pour les évènements d’UI tels que la sélection, conservez l’ID ou l’index dans l’état au lieu de l’objet lui-même. |
There was a problem hiding this comment.
| * Pour les évènements d’UI tels que la sélection, conservez l’ID ou l’index dans l’état au lieu de l’objet lui-même. | |
| * Pour les interactions telles que la sélection d'élément, conservez l’ID ou l’index dans l’état au lieu de l’objet lui-même. |
There was a problem hiding this comment.
Salut @KohdeAvekLeQ !
Avant toute chose, merci pour tout ce boulot ! C'est super cool de nous filer un coup de main.
Écoute c'est vachement mieux, même si j'ai fait pas mal de retours sur cette partie. J'ai revu jusqu'aux Défis, je fais les Défis dans une revue à part dans pas longtemps (GitHub couine assez comme ça dès qu'on dépasse genre 30 commentaires… pfff…)
Tu auras des correctifs à propager toi-même sur plusieurs reprises au fil de la page, je te l'ai indiqué chaque fois que nécessaire.
Beau boulot !
Avant de traiter les retours, lis bien TOUT ce message, notamment les consignes d'intégration optimale des retours par lot(s)
Tout est fait sous forme de Suggestions GitHub, il te suffit à chaque suggestion que tu approuves de
cliquer le bouton d'ajout au lot de modifs à committer (pas de commit direct !), et sur la fin de créer le commit groupé. (ce mode de regroupement en un seul commit est à favoriser absolument, mais tu devras aller dans l'onglet Files changed pour y accéder, il n'est pas utilisable dans l’onglet Conversation)
Si certaines appellent discussion, n'hésite pas, tu réponds, on en parle, on avance ensemble 🤝
Quand tout sera bouclé côté code, je ferai une repasse visuelle finale en local avant de fusionner. J'y recalerai si besoin les usual suspects : espaces insécables avant les ponctuations doubles, et apostrophes françaises.
Encore mille mercis, j'ai hâte de voir cette PR finalisée et dans main !
tdd
added
Reviewing
|
|
||
| This `Clock` component receives two props: `color` and `time`. When you select a different color in the select box, the `Clock` component receives a different `color` prop from its parent component. However, for some reason, the displayed color doesn't update. Why? Fix the problem. | ||
| Ce composant `Clock` reçoit deux props : `color` et `time`. Lorsque vous sélectionnez une couleur différente dans la boîte de sélection, le composant `Clock` reçoit une prop `color` différente de son composant parent. Cependant, la couleur affichée n’est pas mise à jour. Pourquoi ? Corrigez le problème. |
There was a problem hiding this comment.
| Ce composant `Clock` reçoit deux props : `color` et `time`. Lorsque vous sélectionnez une couleur différente dans la boîte de sélection, le composant `Clock` reçoit une prop `color` différente de son composant parent. Cependant, la couleur affichée n’est pas mise à jour. Pourquoi ? Corrigez le problème. | |
| Ce composant `Clock` reçoit deux props : `color` et `time`. Lorsque vous sélectionnez une couleur différente dans la boîte de sélection, le composant `Clock` reçoit une prop `color` différente depuis son composant parent. Cependant, la couleur affichée n’est pas mise à jour. Pourquoi ? Corrigez le problème. |
| @@ -1911,7 +1914,7 @@ export default function App() { | |||
|
|
|||
| <Solution> | |||
|
|
|||
| The issue is that this component has `color` state initialized with the initial value of the `color` prop. But when the `color` prop changes, this does not affect the state variable! So they get out of sync. To fix this issue, remove the state variable altogether, and use the `color` prop directly. | |||
| Le problème est que ce composant a un état `color` initialisé avec la valeur initiale de la prop `color`. Mais quand la prop change, cela n’affecte pas la variable d’état ! Donc elles se désynchronisent. Pour régler ce problème, retirez les variables d’état entièrement, et utilisez la prop `color` directement. | |||
There was a problem hiding this comment.
| Le problème est que ce composant a un état `color` initialisé avec la valeur initiale de la prop `color`. Mais quand la prop change, cela n’affecte pas la variable d’état ! Donc elles se désynchronisent. Pour régler ce problème, retirez les variables d’état entièrement, et utilisez la prop `color` directement. | |
| Le problème, c'est que ce composant a un état `color` initialisé avec la valeur initiale de la prop `color`. Mais quand la prop change, ça n’affecte pas la variable d’état ! Donc elles se désynchronisent. Pour régler ce problème, retirez carrément la variable d’état, et utilisez directement la prop `color`. |
On évite les locutions + "est". On préfère "consiste à", "tient à ce que", "vient de ce que" ou ", c'est que", suivant les cas.
Par ailleurs, comme tu as déjà pu le voir, en français les adverbes sont plus naturellement autour du verbe (avant = épithète, après = attribut) qu'en fin de locution.
| @@ -2017,13 +2020,13 @@ export default function App() { | |||
|
|
|||
| </Solution> | |||
|
|
|||
| #### Fix a broken packing list {/*fix-a-broken-packing-list*/} | |||
| #### Réparer une liste de matériel cassée {/*fix-a-broken-packing-list*/} | |||
There was a problem hiding this comment.
| #### Réparer une liste de matériel cassée {/*fix-a-broken-packing-list*/} | |
| #### Réparer une liste d'affaires cassée {/*fix-a-broken-packing-list*/} |
Packing list = liste des trucs à fourrer dans ses bagages.
| @@ -2017,13 +2020,13 @@ export default function App() { | |||
|
|
|||
| </Solution> | |||
|
|
|||
| #### Fix a broken packing list {/*fix-a-broken-packing-list*/} | |||
| #### Réparer une liste de matériel cassée {/*fix-a-broken-packing-list*/} | |||
There was a problem hiding this comment.
| #### Réparer une liste de matériel cassée {/*fix-a-broken-packing-list*/} | |
| #### Réparer une liste d'affaires cassée {/*fix-a-broken-packing-list*/} |
Packing list = liste des trucs à fourrer dans ses bagages.
| @@ -2736,9 +2739,9 @@ label { width: 100%; padding: 5px; display: inline-block; } | |||
|
|
|||
| </Sandpack> | |||
|
|
|||
| One minor downside of using an array is that for each item, you're calling `selectedIds.includes(letter.id)` to check whether it's selected. If the array is very large, this can become a performance problem because array search with [`includes()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) takes linear time, and you're doing this search for each individual item. | |||
| Un petit inconvénient de l’utilisation d’une liste est que pour chaque élément, vous appelez `selectedIds.includes(letter.id)` pour vérifier si il est sélectionné. Si la liste est très grande, cela peut devenir un problème de performances car rechercher dans une liste avec [`includes()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) prend un temps linéaire, et vous effectuez cette recherche pour chaque élément. | |||
There was a problem hiding this comment.
| Un petit inconvénient de l’utilisation d’une liste est que pour chaque élément, vous appelez `selectedIds.includes(letter.id)` pour vérifier si il est sélectionné. Si la liste est très grande, cela peut devenir un problème de performances car rechercher dans une liste avec [`includes()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) prend un temps linéaire, et vous effectuez cette recherche pour chaque élément. | |
| Utiliser un tableau présente un léger inconvénient : pour chaque élément, vous appelez `selectedIds.includes(letter.id)` pour vérifier s'il est sélectionné. Si la liste est très grande, ça peut devenir un problème de performances car rechercher dans une liste avec [`includes()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) prend un temps linéaire, et vous effectuez cette recherche pour chaque élément. |
Tu vois ici le terme générique "liste" vient t'embêter, parce qu'on parle très techniquement d'un tableau, en fait, du type Array.
|
|
||
| To fix this, you can hold a [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) in state instead, which provides a fast [`has()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/has) operation: | ||
| Pour résoudre ce problème, vous pouvez enregistrer un [Set](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set) dans l’état à la place, qui permet une fonction [`has()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set/has) rapide : |
There was a problem hiding this comment.
| Pour résoudre ce problème, vous pouvez enregistrer un [Set](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set) dans l’état à la place, qui permet une fonction [`has()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set/has) rapide : | |
| Pour résoudre ce problème, vous pouvez plutôt utiliser un [Set](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set) dans l’état, qui fournit une fonction [`has()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Set/has) rapide : |
Note pour la suite que le plus simple pour le MDN est en fait de juste enlever la langue (/en-us/→ /) : le lien est réécrit dynamiquement selon dispo dans la langue du visiteur, et ramène sur en-US à défaut d'une trad existante. Ça évite d'avoir à vérifier à chaque fois.
|
|
||
| Keep in mind that you [should not mutate objects in state](/learn/updating-objects-in-state), and that includes Sets, too. This is why the `handleToggle` function creates a *copy* of the Set first, and then updates that copy. | ||
| Gardez en tête que vous [ne devez pas muter des objets dans l’état](/learn/updating-objects-in-state), et cela inclut les Sets aussi. C’est pourquoi la fonction `handleToggle` crée d’abord une *copie* de ce Set, puis la met à jour. |
There was a problem hiding this comment.
| Gardez en tête que vous [ne devez pas muter des objets dans l’état](/learn/updating-objects-in-state), et cela inclut les Sets aussi. C’est pourquoi la fonction `handleToggle` crée d’abord une *copie* de ce Set, puis la met à jour. | |
| Gardez en tête que vous [ne devez pas modifier des objets dans l’état](/learn/updating-objects-in-state), et ça inclut aussi les Sets. C’est pourquoi la fonction `handleToggle` crée d’abord une *copie* de ce Set, puis la met à jour. |
cf. Glossaire : on ne dit jamais "muter".
tdd
removed
the
Reviewing
|
Coucou @KohdeAvekLeQ auras-tu le temps cette semaine de traiter ma revue pour que je puisse faire une repasse finale et intégrer ça ? |
|
Hello, oui je vais essayer de faire ça ce soir ou demain ! |
No description provided.