Gérer l'état

À mesure que votre application grandit, il est utile d'être plus intentionnel sur la façon dont votre état est organisé et comment les données circulent entre vos composants. Un état redondant ou dupliqué est une source courante de bugs. Dans ce chapitre, vous apprendrez comment bien structurer votre état, comment maintenir la logique de mise à jour de l'état et comment partager l'état entre des composants distants.

Réagir aux entrées avec l'état

Avec React, vous ne modifierez pas l'interface utilisateur directement depuis le code. Par exemple, vous n'écrirez pas de commandes comme « désactiver le bouton », « activer le bouton », « afficher le message de succès », etc. Au lieu de cela, vous décrirez l'interface utilisateur que vous souhaitez voir pour les différents états visuels de votre composant (« état initial », « état de saisie », « état de succès »), puis vous déclencherez les changements d'état en réponse aux entrées de l'utilisateur. Cela est similaire à la façon dont les designers conçoivent les interfaces utilisateur.

Voici un formulaire de quiz construit avec React. Notez comment il utilise la variable d'étatstatuspour déterminer s'il faut activer ou désactiver le bouton d'envoi, et s'il faut afficher le message de succès à la place.

Choisir la structure de l'état

Bien structurer l'état peut faire la différence entre un composant agréable à modifier et déboguer, et un composant qui est une source constante de bugs. Le principe le plus important est que l'état ne doit pas contenir d'informations redondantes ou dupliquées. S'il y a un état inutile, il est facile d'oublier de le mettre à jour et d'introduire des bugs !

Par exemple, ce formulaire a une variable d'étatredondantefullName :

Vous pouvez la supprimer et simplifier le code en calculantfullNamependant le rendu du composant :

Cela peut sembler être un petit changement, mais de nombreux bugs dans les applications React sont corrigés de cette façon.

Partager l'état entre les composants

Parfois, vous souhaitez que l'état de deux composants change toujours ensemble. Pour ce faire, retirez l'état des deux composants, déplacez-le vers leur parent commun le plus proche, puis transmettez-le-leur via les props. C'est ce qu'on appelle « remonter l'état », et c'est l'une des choses les plus courantes que vous ferez en écrivant du code React.

Dans cet exemple, un seul panneau doit être actif à la fois. Pour y parvenir, au lieu de conserver l'état actif dans chaque panneau individuel, le composant parent détient l'état et spécifie les props pour ses enfants.

Préserver et réinitialiser l'état

Lorsque vous re-rendez un composant, React doit décider quelles parties de l'arborescence conserver (et mettre à jour), et quelles parties supprimer ou recréer à partir de zéro. Dans la plupart des cas, le comportement automatique de React fonctionne assez bien. Par défaut, React préserve les parties de l'arborescence qui « correspondent » à l'arborescence de composants précédemment rendue.

Cependant, parfois ce n'est pas ce que vous souhaitez. Dans cette application de chat, taper un message puis changer de destinataire ne réinitialise pas la saisie. Cela peut amener l'utilisateur à envoyer accidentellement un message à la mauvaise personne :

React vous permet de remplacer le comportement par défaut et deforcerun composant à réinitialiser son état en lui passant unekeydifférente, comme<Chat key={email} />. Cela indique à React que si le destinataire est différent, il doit être considéré comme uncomposantChatdifférent qui doit être recréé à partir de zéro avec les nouvelles données (et l'interface utilisateur comme les champs de saisie). Maintenant, passer d'un destinataire à l'autre réinitialise le champ de saisie, même si vous affichez le même composant.

Extraire la logique d'état dans un réducteur

Les composants avec de nombreuses mises à jour d'état réparties dans de nombreux gestionnaires d'événements peuvent devenir accablants. Pour ces cas, vous pouvez consolider toute la logique de mise à jour de l'état en dehors de votre composant dans une seule fonction, appelée « réducteur ». Vos gestionnaires d'événements deviennent concis car ils ne spécifient que les « actions » de l'utilisateur. Au bas du fichier, la fonction réducteur spécifie comment l'état doit être mis à jour en réponse à chaque action !

Transmettre des données en profondeur avec le contexte

Habituellement, vous transmettez des informations d'un composant parent à un composant enfant via les props. Mais passer des props peut devenir peu pratique si vous devez faire passer une prop à travers de nombreux composants, ou si de nombreux composants ont besoin de la même information. Le contexte permet au composant parent de rendre certaines informations disponibles à n'importe quel composant dans l'arbre en dessous de lui—peu importe sa profondeur—sans les transmettre explicitement via les props.

Ici, le composantHeadingdétermine son niveau de titre en « demandant » auSectionle plus proche son niveau. ChaqueSectionsuit son propre niveau en demandant auSectionparent et en y ajoutant un. ChaqueSectionfournit des informations à tous les composants en dessous sans passer de props—il le fait via le contexte.

Passer à l'échelle avec réducteur et contexte

Les réducteurs vous permettent de consolider la logique de mise à jour de l'état d'un composant. Le contexte vous permet de transmettre des informations en profondeur à d'autres composants. Vous pouvez combiner réducteurs et contexte pour gérer l'état d'un écran complexe.

Avec cette approche, un composant parent avec un état complexe le gère avec un réducteur. D'autres composants, n'importe où en profondeur dans l'arbre, peuvent lire son état via le contexte. Ils peuvent également dispatcher des actions pour mettre à jour cet état.

Et ensuite ?

Rendez-vous surRéagir aux saisies avec l'étatpour commencer à lire ce chapitre page par page !

Ou, si vous êtes déjà familier avec ces sujets, pourquoi ne pas lire à propos desÉchappatoires?