React : composants, état et flux

React : composants, état et flux

1. Composants et props : la_descendance par le haut

   React est une bibliothèque d'interface. Elle ne favorise aucune architecture : elle fournit un mécanisme de composition, et c'est à l'équipe de décider de la manière de l'organiser.

   Un composant est une fonction

   Un composant prend des propriétés (props) en entrée et rend du JSX en sortie. Il ne contient pas de logique de gestion d'état global : il décrit ce qui doit s'afficher, et rien d'autre.

   function CarteUtilisateur({ nom, role }: { nom: string; role: string }) {
     return (
       <div className="carte">
         <h3>{nom}</h3>
         <p>{role}</p>
       </div>
     );
   }

   Les props descendent, les événements remontent

   C'est le principe central de React, et il faut le retenir tel quel : les données circulent dans un seul sens. Un parent transmet une donnée à un enfant, l'enfant ne peut jamais la modifier directement. S'il doit agir dessus, il remonte un événement, et le parent décide.

   Ce qui paraît être une contrainte est un garde-fou : impossible qu'un enfant modifie un état partagé sans que le parent le sache. Les bugs d'état impossible à retrouver disparaissent, parce que le chemin de modification est unique et visible.

   Conditionner le rendu

   En JSX, une expression conditionnelle simple s'écrit avec l'opérateur logique. Le rendu conditionnel n'est pas une déclaration if à écrire dans la balise, mais une expression à évaluer.

   Ce que les framework modernes corrigent par rapport aux premières versions : le retour direct d'un fragment de liste sans clé. La clé d'un élément de liste n'est pas décorative — elle indique à React quel élément est lequel entre deux rendus. Une clé absente ou generada par l'index produit des mélanges d'état silencieux quand la liste est réordonnée : les données restent dans la mauvaise ligne sans aucune erreur visible.

2. Les hooks : état local et effets

   Les hooks sont des fonctions qui permettent d'utiliser l'état et le cycle de vie dans un composant fonction. Ils commencent par use, et c'est la convention de les appeler au niveau racine du composant.

   useState : l'état local

   Il retourne l'état et une fonction pour le modifier. La fonction de mise à jour ne fusionne pas la valeur : elle la remplace et ne reçoit pas l'ancienne automatiquement. C'est la source d'erreur la plus fréquente de l'apprentissage : deux mises à jour dans la même boucle, et la seconde écrase la première.

   La forme « mise à jour par fonction » existe précisément pour cela : elle reçoit la valeur précédente, et deux mises à jour successives se cumulent correctement.

   useEffect : synchroniser avec l'extérieur

   Un effet sert à synchroniser le composant avec une ressource extérieure : appel réseau, abonnement à un événement, minuterie, manipulation directe du DOM. Ce n'est pas un « code qui s'exécute après le rendu », c'est une synchronisation dont il faut nettoyer l'effet précédent.

   La fonction de retour est le nettoyage : elle annule l'abonnement, annule la requête en cours, arrête la minuterie. Oublier ce retour est un bug qui ne se voit pas : l'application fonctionne, et fuit des ressources à chaque changement d'état.

   La seconde règle du tableau de dépendances compte autant : une dépendance manquante produit un comportement faux parce que l'effet lit une valeur qui sera périmée. Ce n'est pas un avertissement, c'est la définition même d'une closure obsolète.

   Les trois fautes classiques, et comment elles s'annoncent

   • dépendances de tableau vides alors que l'effet lit une prop : l'effet ne se relance pas et lit une valeur périmée ;
   • nettoyage oublié : accumulation de ressources ou écouteurs doublés ;
   • effet utilisé pour dériver un état : si le résultat se calcule à partir d'autres valeurs, il n'a pas besoin d'être stocké du tout. Un effet qui ne fait que recalculer autre chose est une source de désynchronisation inutile.

3. Performance : mesurer avant d'optimiser

   React rejoue le rendu d'un composant quand son état change ou quand une prop change de valeur. C'est généralement ce qu'on veut, et c'est la base de la simplicité du modèle.

   Avant d'optimiser : ce qu'il faut savoir

   La longueur de la prop est le coût réel. Un rendu de composant ne coûte pas cher en soi ; ce qui coûte est le travail déclenché en aval, sur des sous-arbres volumineux. Un parent qui rejoue son rendu n'a pas forcément un problème, si ses enfants sont peu nombreux ou peu coûteux.

   Les trois leviers, dans cet ordre

   1. remonter l'état : un état placé trop haut force des rendus en cascade dans tout l'arbre. Le déplacer vers le bas est souvent la seule correction nécessaire, et elle ne coûte rien ;
   2. stabiliser les références : une fonction ou un objet recréé à chaque rendu est une nouvelle valeur, donc une nouvelle raison de rejouer le rendu. useCallback et useMemo servent à cela ;
   3. mémoriser explicitement (memo) : le dernier recours, car ça complique la lecture et ça a un coût mémoire.

   La règle de ce cours

   Un hook de performance s'écrit avec une justification mesurée : quel rendu a été mesuré comme coûteux, avec quel outil, à quel seuil. Sans mesure, useMemo everywhere n'améliore rien et rend le code nettement plus difficile à suivre. Le profil de rendu reste la seule preuve acceptable — et l'optimisation non mesurée est une dette, pas une amélioration.