React évolue vite, mais les applications qui vieillissent bien ont des points communs qui changent peu. Voici les pratiques que nous appliquons sur nos projets, et pourquoi.
1. Des composants petits, qui font une seule chose
Un composant de 400 lignes qui charge des données, gère un formulaire et affiche un tableau est difficile à lire, à tester et à réutiliser. Découpez-le : un composant pour l'affichage, un autre pour la logique. Si vous peinez à lui trouver un nom précis, c'est souvent qu'il fait trop de choses.
2. Garder l'état au plus près de son usage
Un état placé trop haut dans l'arbre provoque des rendus inutiles et oblige à faire descendre des props sur plusieurs niveaux. Commencez par un état local. Remontez-le seulement quand deux composants en ont réellement besoin, et ne sortez un gestionnaire d'état global que pour ce qui est vraiment global : utilisateur connecté, langue, thème.
3. Ne pas stocker ce qui peut se calculer
Si une valeur se déduit des props ou d'un autre état, calculez-la pendant le rendu au lieu de la copier dans un second état synchronisé par un useEffect. Deux états à maintenir d'accord sont une source classique de bugs.
4. Réserver useEffect au monde extérieur
Un effet sert à synchroniser un composant avec quelque chose d'extérieur à React : une API du navigateur, un abonnement, une bibliothèque tierce. Pour réagir à un clic, mettez le code dans le gestionnaire d'événement. Pour transformer des données, faites-le pendant le rendu.
5. Charger les données côté serveur quand c'est possible
Avec les Server Components et des frameworks comme Next.js, une bonne partie des données peut être chargée sur le serveur. La page arrive déjà remplie, le navigateur télécharge moins de JavaScript, et les moteurs de recherche lisent le contenu sans effort. Gardez les composants client pour ce qui est interactif.
6. TypeScript, partout
Typer les props d'un composant revient à écrire sa documentation, vérifiée par le compilateur. Les erreurs de nom ou de forme de données sont signalées dans l'éditeur, pas en production.
7. Mesurer avant d'optimiser
useMemo et useCallback ont un coût en lisibilité. Utilisez le profileur de React pour trouver ce qui est réellement lent avant d'en ajouter. Le plus souvent, le gain vient d'ailleurs : listes trop longues à virtualiser, images trop lourdes, code chargé trop tôt.
8. L'accessibilité dès le départ
Un vrai <button> plutôt qu'une <div> cliquable, un label pour chaque champ, un texte alternatif pour chaque image, une navigation possible au clavier. C'est bien moins coûteux à faire au fur et à mesure qu'à corriger après coup.
9. Tester ce que voit l'utilisateur
Un test qui clique sur un bouton et vérifie le texte affiché survit aux refontes internes. Un test qui inspecte l'état d'un composant casse à chaque modification. Privilégiez les premiers.
En résumé
Aucune de ces pratiques n'est spectaculaire. Appliquées ensemble, elles donnent un code qu'une nouvelle personne peut comprendre rapidement et modifier sans crainte : c'est ce qui fait la différence sur la durée d'un projet.