Un peu sur les bibliothèques de composants Web

Il y a eu beaucoup de nouvelles sur les composants Web récemment, et je les trierai ici.

Je pense que l'un des meilleurs scénarios d'application pour les composants Web est la bibliothèque de modèles. Au lieu de l'utiliser comme bootstrap<div> , ou utilisez-le comme Bulma<code><div> , il est préférable d'utiliser des éléments personnalisés, par exemple<code><designsystem-tabs></designsystem-tabs> . La nouvelle bibliothèque Shoelace utilise l'espace de noms sl pour définir ses composants. Il s'agit d'une bibliothèque de schéma qui est entièrement basée sur des composants Web, où les balises sont<sl-tab-group></sl-tab-group> élément.

Quels sont les avantages de faire cela? Tout d'abord, il introduit le modèle de composant. Cela signifie que si vous travaillez sur un composant, il aura un modèle et une feuille de style liée à son emplacement. En regardant l'implémentation interne de Shoelace, vous pouvez voir que tout est basé sur le pochoir.

Un autre avantage est que le composant peut utiliser (et utilise) un Dom Shadow. Cela fournit un mécanisme d'isolement directement de la plate-forme Web. Pour nous, les développeurs CSS, cela signifie que le style des balises dans le composant TAG est effectué en utilisant la classe .tab (wow, c'est tellement cool!), Mais c'est isolé dans ce composant. Même avec un tel nom générique, je n'affecterais pas accidentellement d'autres composants de la classe commune sur la page, et il n'y aurait pas de CSS externe pour interférer avec la structure interne ici. Shadow Dom est comme un mur de sécurité qui empêche les styles de fuir ou d'infiltration.

Je vois également le framework FAST¹ qui est également un ensemble de composants. Sa balise est définie comme<fast-tabs></fast-tabs> . Cela me rappelle un autre avantage des composants Web en tant que méthode de bibliothèque de schéma: il a l'impression qu'il est axé sur l'API, en commençant même par le nom du composant lui-même, ce qui est en fait ce que vous utilisez dans HTML. Les propriétés de cet élément peuvent être complètement personnalisées. La norme émergente semble être que vous n'avez même pas besoin d'ajouter data- préfixe aux propriétés personnalisées. Donc, si je veux faire un composant de balise, cela pourrait être<chris-tabs active-tab="lunch" variation="rounded"></chris-tabs> .

Peut-être le plus grand acteur utilisant des composants Web comme bibliothèque de schéma est ionique. Leurs étiquettes sont<ion-tabs></ion-tabs> , vous pouvez les utiliser sans impliquer d'autres cadres (bien qu'ils prennent en charge Angular, React et Vue en plus de leur propre pochoir). Ionic a fait de grands progrès dans les composants Web et a récemment pris en charge les parties de l'ombre. Voici à nouveau l'explication de Brandy Carney expliquant l'emballage:

Shadow Dom aide à empêcher les styles de fuir des composants et d'être appliqués accidentellement à d'autres éléments. Par exemple, nous attribuons .buttonclass à notre<ion-button></ion-button> Composants. Si l'utilisateur de framework ionique définit la classe .button sur l'un de ses propres éléments, dans les versions antérieures du cadre, il hérite du style de bouton ionique. parce que<ion-button></ion-button> C'est maintenant un composant Web Shadow, donc ce problème n'existe plus.

Cependant, en raison de cette encapsulation, le style ne peut pas pénétrer dans les éléments internes de la composante ombre. Cela signifie que si le composant de l'ombre rend des éléments dans son arbre d'ombre, l'utilisateur ne peut pas utiliser son CSS pour localiser les éléments internes.

L'encapsulation est une bonne chose, mais cela rend le style "plus difficile" (délibérément). Il existe un concept CSS important à comprendre: les propriétés personnalisées CSS peuvent pénétrer l'ombre DOM . Mais il n'est pas sage pour les gens de décider - je pense que c'est vrai - pour «varier» tout dans un système de conception. Au lieu de cela, ils donnent à chaque fragment HTML dans la pièce Shadow Dom, par exemple<div part="icon"> , ce qui nous permet de "accéder à l'extérieur" en utilisant CSS, par exemple <code>custom-component::part(icon) { } . Je pense que les crochets de style basés sur des pièces sont principalement bons et une solution sensée pour une bibliothèque de modèles comme celle-ci, mais j'avoue qu'une partie de cela me dérange. Le sélecteur fonctionne différemment que prévu. Par exemple, vous ne pouvez pas sélectionner le contenu conditionnellement. Vous ne pouvez pas non plus sélectionner des éléments enfants ou utiliser des cascades. En d'autres termes, c'est juste un seul-off, ou comme si vous passiez directement à travers le film avec vos mains. Vous pouvez atteindre l'avant et prendre quelque chose ou non, mais vous ne pouvez rien faire.

En parlant de choses qui mettent les gens en colère, Andrea GiamMarchi a un bon point de vue sur la situation actuelle des composants Web:

Chaque bibliothèque qui a commencé avec, y compris la mienne, suggère que nous devons importer la bibliothèque pour définir ce qu'on appelle un " élément personnalisé portable ".

Google recommande toujours d'utiliser le litre. Microsoft veut que vous utilisiez la vitesse. Le pochoir a ses propres composants. HyperHTML a ses propres composants. Personne n'utilise uniquement des composants Web "bruts". C'est très étrange! Le pire que je pense, c'est que les composants Web devraient être une chose de "plate-forme native", ce qui signifie que nous ne devrions pas avoir besoin de compter sur une technologie particulière pour les utiliser. Lorsque nous faisons cela, nous y sommes verrouillés comme l'utilisation de React ou quoi que ce soit d'autre.

Andrea présente quelques idées dans l'article, notamment en utilisant des bibliothèques nouvelles et plus petites. Je pense que ce que je veux voir est une bibliothèque de schéma qui n'utilise aucune bibliothèque.

1. Fast s'appelle un "système d'interface" dans une phrase continue sur la page d'accueil, suivie d'un "framework d'interface utilisateur". Shoelaces s'appelle une "bibliothèque", mais je l'appelle une "bibliothèque de mode". Je pense que le «système de conception» est le terme le plus couramment utilisé pour décrire ce concept, mais est souvent plus étendu qu'une technologie particulière. Fast utilise ce terme dans le code lui-même pour désigner l'élément wrapper qui contrôle le sujet. Je ne pense pas que la terminologie entourant tout cela soit loin d'être certain.