Web components : éléments personnalisés, DOM fantôme, et où s'arrête l'encapsulation

Ce que c'est

Trois fonctionnalités du navigateur composent les web components. Éléments personnalisés : une classe étendant HTMLElement, enregistrée avec customElements.define("x-name", Class) (le nom doit contenir un trait d'union), avec connectedCallback, disconnectedCallback et attributeChangedCallback pour les attributs listés dans un tableau statique observedAttributes. DOM fantôme : attachShadow({ mode: "open" }) donne à l'élément un sous-arbre privé ; MDN précise que les styles qui s'y trouvent sont confinés à cet arbre, de sorte que les styles de la page n'affectent pas les éléments fantômes et que les styles fantômes n'affectent pas la page, et <slot> projette les enfants du DOM clair à l'intérieur. Templates : <template> contient du balisage inerte, et <template shadowrootmode="open"> déclare une racine fantôme dans du HTML rendu côté serveur, sans script.

Pourquoi c'est important

Les éléments personnalisés sont le seul modèle de composant que le navigateur lui-même comprend nativement : ils fonctionnent dans n'importe quel framework ou sans framework, survivent aux migrations de frameworks et peuvent être utilisés depuis du HTML simple rendu côté serveur. Le prix à payer est que l'encapsulation est réelle, et que chaque préoccupation qui traverse la frontière (thématisation, formulaires, labels, focus, événements) exige une ouverture explicite.

Comment l'appliquer

• Exposer délibérément des surfaces de style : des propriétés personnalisées pour les valeurs (elles s'héritent dans l'arbre fantôme), et part="label" sur les éléments internes afin que la page puisse écrire x-name::part(label) ; MDN décrit part comme rendant un élément fantôme visible au DOM parent.
• Faire des contrôles de formulaire des participants réels avec static formAssociated = true et ElementInternals (setFormValue, setValidity) ; sans cela, une entrée personnalisée ne soumet jamais de valeur.
• Préférer les éléments autonomes ; MDN note que Safari ne prévoit pas de prendre en charge les éléments intégrés personnalisés (is="...").
• Rendre l'état initial avec du DOM fantôme déclaratif quand le premier rendu ou les robots d'indexation comptent, puis mettre à niveau avec la classe.
• Refléter les états importants sous forme d'attributs afin que le CSS et les tests puissent les sélectionner ; garder mode: "open" (MDN indique que le mode fermé n'est pas un mécanisme de sécurité fort, seulement un signal).
• Styler x-name:not(:defined) pour la période avant l'exécution du script, afin que le contenu ne saute pas à la mise à niveau.

Pièges

Les références d'ID ne traversent pas la frontière : un <label for> ou un aria-labelledby dans la page ne peut pas pointer vers une entrée à l'intérieur de l'arbre fantôme, il faut donc soit injecter le contrôle depuis le DOM clair via un slot, soit le labelliser à l'intérieur. Les réinitialisations globales, les classes utilitaires et les sprites d'icônes ne s'appliquent pas à l'intérieur. Les événements personnalisés ont besoin de composed: true pour être entendus à l'extérieur. Enregistrer deux fois le même nom lève une exception, ce qui pose problème quand deux paquets livrent le même composant. Les outils de développement affichent l'arbre fantôme, mais pas document.querySelector.