Quand deux composants semblables devraient rester séparés

Deux cartes peuvent avoir un air de famille et répondre à des exigences différentes.

Dans yesid.dev-design, les contrats documentés de Transit et de yesid.dev rendent cette différence concrète. Transit demande une carte plate, sans ombre ni bordure en relief. yesid.dev conserve un biseau et une ombre au survol. Les deux appartiennent à la même famille visuelle. Leurs exigences ne sont pourtant pas les mêmes.

On pourrait placer les deux comportements dans un composant partagé et lui faire vérifier le nom du produit. Les règles du projet excluent justement ce lien. Dès que le code commun connaît chaque produit par son nom, toute nouvelle exception ajoute une raison de modifier la base.

La limite que j'ai choisie est plus petite. Le composant partagé prend en charge la commande ou la surface commune. Un style ou une adaptation propre au produit prend en charge la différence. Chaque produit conserve les vérifications qui expliquent pourquoi son exception existe.

Cette décision laisse une part de duplication. Elle lui donne aussi une raison et un endroit précis.

La question est de savoir si les deux éléments ont la même responsabilité. Leur apparence actuelle donne un indice, mais elle ne dit pas tout de leur comportement, de la gestion de leur état ou des changements qu'ils devraient recevoir ensemble.

Une section repliable en est un autre exemple. Les deux produits peuvent afficher un titre, un chevron et du contenu masqué. Ils peuvent tout de même différer dans la mémorisation de l'état, la composition de l'en-tête et le comportement du contenu fermé. Des commandes de base partagées restent utiles. Partager toute la section ferait aussi remonter des décisions qui appartiennent encore au produit.

Le dépôt applique une règle de trois aux composants composés : trois consommateurs indépendants doivent demander le même contrat avant sa mise en commun. C'est une contrainte de ce projet, pas une formule universelle. Elle oblige à prendre un recul utile avant de considérer qu'une ressemblance justifie une abstraction stable.

Il y a aussi une conséquence sur les mises à jour. Dès qu'un composant devient partagé, sa modification concerne plusieurs produits. Chacun adopte une version précise et révise son propre comportement. Un exemple qui fonctionne dans la galerie ne répond pas à toutes les questions d'une vraie page.

Cette façon de réfléchir rend la réutilisation plus concrète. Qu'est-ce qui se répète? Qu'est-ce qui diffère? Quelles différences sont voulues? Qui décide du moment où elles changent?

La réponse peut être un composant commun. Elle peut aussi être un petit élément partagé avec une adaptation locale, ou deux réalisations séparées dont les responsabilités évoluent encore. Ce qui compte, c'est de pouvoir expliquer et vérifier la limite choisie.

Découvrir le projet