Web Component

Un Web Component est un élément HTML personnalisé, réutilisable et encapsulé, construit à partir de standards natifs du navigateur : les Custom Éléments, le Shadow DOM et la balise template. Il s'utilise comme une balise ordinaire, dans n'importe quelle page, sans dépendre d'un framework.

Un composant React ou Vue n'existe que dans son écosystème : sorti de son application, il ne s'affiche pas. Un Web Component, lui, est compris directement par le navigateur, au même titre qu'une balise video ou details. C'est la différence entre une pièce sur mesure et une pièce standardisée qui s'emboîte partout.

Comment ça marche

Trois briques se combinent. Les Custom Éléments permettent de déclarer une nouvelle balise, dont le nom doit obligatoirement contenir un tiret, et d'y rattacher une classe JavaScript. Cette classe expose des méthodes de cycle de vie que le navigateur appelle tout seul : à l'insertion dans la page, au retrait, et à chaque modification d'un attribut observé. Le Shadow DOM isole le balisage interne et les styles du composant du reste du document. La balise template, associée aux slots, fournit une structure inerte que le composant clone et dans laquelle il vient placer le contenu fourni par la page hôte.

La communication suit une règle simple, héritée du HTML natif : les données entrent par les attributs et les propriétés, les informations sortent sous forme d'événements personnalisés que la page hôte écoute.

À quoi ça sert concrètement

• Diffuser un design system commun à plusieurs applications qui n'utilisent pas le même framework
• Distribuer un widget embarqué chez un client tiers sans que son CSS ne vienne casser le vôtre
• Découper un grand site en micro-frontends développés par des équipes séparées
• Faire durer une brique d'interface plus longtemps que le framework du moment
• Moderniser progressivement un site ancien, balise après balise, sans réécriture globale

Les pièges

• Le rendu côté serveur reste délicat : le Declarative Shadow DOM améliore la situation, mais le sujet demande de la vigilance
• L'accessibilité traverse mal la frontière du Shadow DOM : gestion du focus, association entre un libellé et un champ, attributs ARIA, tout cela demande un travail explicite
• Le style depuis l'extérieur n'est possible que si vous l'avez prévu, via des variables CSS personnalisées et des parties exposées
• Un champ personnalisé ne participe pas à un formulaire natif tant qu'il n'a pas été déclaré comme tel et raccordé à l'API interne des éléments

Quand le choisir

Choisissez-le quand plusieurs équipes, plusieurs technologies ou plusieurs sites doivent partager les mêmes briques d'interface, ou quand vous livrez du code qui s'exécutera dans une page que vous ne contrôlez pas. Évitez-le si votre produit est une application unique et homogène : les composants du framework y sont plus rapides à écrire, mieux typés et bien mieux outillés.