Composant
Définition
Brique réutilisable d'une interface (bouton, card, formulaire) qui contient son propre rendu et sa logique. Base de l'architecture React et de tout design system moderne.
Qu'est-ce qu'un composant
Un composant est une brique réutilisable de l'interface, qui regroupe son rendu (HTML/JSX), ses styles (CSS/Tailwind) et sa logique (gestion d'état, événements). Un bouton, une card, un formulaire, un graphe, une modale sont autant de composants. En React, ils sont représentés par des fonctions qui prennent des props et retournent du JSX. Cette approche s'oppose aux templates monolithiques d'autrefois où une page entière vivait dans un fichier HTML géant impossible à factoriser.
La composabilité
L'idée centrale est la composition : on construit des composants simples (atomes), puis on les assemble pour faire des composants plus complexes (molécules), et finalement des pages entières (organismes et templates). C'est l'application du Atomic Design en code. Un Input et un Label se combinent pour former un Field, qui se combine en SignupForm, qui se combine en SignupPage. Chaque étage est testable et réutilisable indépendamment. C'est plus maintenable que dupliquer le même HTML partout, et c'est ce qui permet de tenir des UI complexes sur la durée.
Les props et l'API
Un composant communique avec son parent via les props : on passe des valeurs (string, number, boolean, function) qui paramètrent son comportement et son rendu. Un bon composant a des props nommées explicitement (variant, size, onClick) plutôt qu'un blob d'options. Les props ont des valeurs par défaut sensées, ce qui rend l'utilisation simple dans le cas courant. Le typage TypeScript des props sert de documentation : un développeur qui survole le composant dans son éditeur voit immédiatement ce qu'il accepte et ce qu'il rend.
Les bonnes pratiques
Quelques règles. Un composant a une responsabilité claire : un Button ne gère pas la navigation, un NavBar ne gère pas les styles d'un input. Quand un composant fait trop de choses, c'est le signal qu'il faut le scinder. Les composants présentationnels (rendu pur) sont séparés des composants connectés (qui chargent des données). Les noms suivent le PascalCase et reflètent l'intention (LoginForm, pas Form1). Les fichiers contiennent un composant principal par fichier, avec ses sous-composants liés. La structure du dossier reflète la hiérarchie de l'app.
Server Component versus Client Component
Sur Next.js App Router, on distingue Server Components (par défaut) et Client Components ("use client"). Un Server Component tourne sur le serveur, peut interroger directement la base, n'envoie pas son JS au client. Un Client Component permet l'interactivité (hooks React, event handlers, état local). La règle pratique : commencer par un Server Component, basculer en client uniquement quand on a besoin d'interactivité. La frontière doit être placée aussi profondément que possible dans l'arbre pour maximiser les bénéfices serveur.
Les pièges à éviter
Quatre pièges. Le composant Dieu qui fait tout (rendu, fetch, état, navigation), qui devient impossible à maintenir. Les props explosion : un composant qui accepte vingt props, signe qu'il fait trop ou que la composition est mauvaise. La duplication subtile : on recopie un composant avec une petite variation au lieu d'ajouter un variant. Le couplage caché : un composant qui dépend implicitement d'un parent précis. La règle qui résume : un composant doit être utilisable dans une démo isolée. Si ce n'est pas le cas, il faut le refactorer.