Les pièces CSS vous sauvent d'un cauchemar

Contexte nécessaire

Récemment, j'écoutais un podcast bien connu, et les animateurs géniaux parlaient de composants Web, répertoriant tous les bons, mauvais et mauvais côtés des différentes spécifications et fonctionnalités des composants Web.

Merci à Chris Coyier et Dave Rupert pour cet épisode totalement juste et cette excellente conversation. Écoutez l'épisode ici :

Talk Show du magasin

Quoi qu'il en soit, au plus profond de cet épisode, j'ai été surpris de constater que CSS Parts figurait sur la liste des méchants, même si je peux voir certaines des raisons pour lesquelles les gens pourraient penser qu'ils ne sont pas les meilleurs. Je pense que non seulement les parties CSS sont plutôt bonnes, mais qu'elles sauvent en fait tous ceux d'entre nous qui les utilisons d'un scénario BEAUCOUP plus ennuyeux et frustrant que de ne pas pouvoir styliser chaque élément à l'intérieur d'une racine fantôme de composant Web exactement comme tu veux.

Laissez-moi vous expliquer, mais d'abord PLUS de contexte !

Les composants Web ont été conçus principalement pour une utilisation par des tiers

Je ne peux pas vérifier explicitement que tout ce qui suit est vrai, mais mon opinion personnelle (créée en écrivant, en utilisant et en aidant à spécifier les fonctionnalités des composants Web au cours des dernières années dans mon travail quotidien) est que les spécifications et fonctionnalités des composants Web existants ont tous été conçus pour résoudre le cas d'utilisation des « composants tiers ». Autrement dit, les composants Web ont été conçus pour prendre en charge une situation très spécifique : un auteur de composant créant un outil que d'autres consommateurs téléchargent sur Internet et utilisent dans leurs applications.

Je pense que si vous examinez les fonctionnalités des composants Web à travers le prisme du cas d'utilisation des "composants tiers", alors une grande partie de l'approche adoptée par les rédacteurs de spécifications et les implémenteurs de navigateurs a une tonne de sens. Prenons par exemple la gravité de l'encapsulation du style shadow dom. Si vous extrayez un composant d'Internet et l'intégrez à votre application, n'est-il pas merveilleux de ne pas avoir à craindre que le CSS de ce composant brise d'une manière ou d'une autre l'une de vos pages ? N'est-il pas merveilleux de ne pas avoir à vous soucier de la structure interne d'un composant que vous n'avez pas écrit et de pouvoir traiter ce composant comme une boîte noire et d'interagir avec lui via une surface API bien définie ?

Le plus gros problème pour comprendre comment les composants Web sont conçus pour fonctionner est que l'industrie a évolué depuis la création des spécifications des composants Web et qu'aujourd'hui, 99 % des composants que nous utilisons dans nos applications ne proviennent pas de sources externes. . De nos jours, lorsque nous pensons aux composants, nous pensons la plupart du temps à un « composant propriétaire » que nous ou notre équipe avons écrit et non une personne sur Internet. Nous n'utilisons pas beaucoup de composants externes dans nos applications, donc les API de composants Web conçues principalement pour ce cas d'utilisation nous semblent étranges, surtout lorsque nous essayons également d'utiliser des composants Web pour créer nous-mêmes des composants propriétaires.

Donc, pour tout le reste que je vais dire dans cet article, supposons que je fais référence à la situation des « composants tiers ». Imaginez que le composant dont je parle est un package npm que vous avez téléchargé et qu'il existe un fichier Lisez-moi GitHub, des notes de mise à jour, etc., mais que vous (ou votre équipe) ne l'avez pas écrit vous-même pour votre propre application.

Les pièces CSS ne sont pas une excellente interface pour styliser les composants que vous écrivez pour vous-même ou votre équipe et sur lesquels vous avez un contrôle total.

Les parties CSS font partie de l'API publique d'un composant Web

Les composants bien conçus ont plusieurs manières différentes d'interagir avec eux. Les excellents composants Web disposent d'emplacements pour du HTML personnalisé, de propriétés personnalisées CSS pour des thèmes personnalisés et de parties CSS pour des styles personnalisés. Les gars du Shop Talk Show ont discuté des parties CSS dans le contexte étant qu'elles sont maladroites pour le style de forme libre, mais je ne penserais pas aux parties CSS de cette façon. Je les considérerais comme une autre surface d'API publique pour le composant, de la même manière que les attributs ou les propriétés. Les gens ne s'inquiètent généralement pas trop de ne pas pouvoir créer des propriétés ou des attributs personnalisés pour les composants qu'ils extraient d'Internet. Je pense que les parties CSS sont la même idée. L'auteur du composant désigne les éléments du modèle interne qui peuvent être « stylisés » comme vous le souhaitez. Donc, être capable de styliser chaque élément interne de ce composant Web shadow dom ne devrait pas nécessairement être une attente.

Et qui de mieux que l'auteur du composant pour savoir quelles parties d'un modèle complexe peuvent appliquer n'importe quel style ? Si vous extrayez un composant d'Internet juste pour retourner et réécrire tous les styles, détruisant éventuellement l'accessibilité et autres dans le processus, pourquoi avez-vous installé le composant en premier lieu ? Je comprends l'attrait du sélecteur "Je sais ce que je fais" pour les racines fantômes que beaucoup de gens ont préconisé, mais dans la section suivante, je vais expliquer pourquoi je pense avoir une surface API de style définie qui est déconnecté de la structure interne du DOM est en fait incroyable et devrait être célébré pour nous aider tous, les développeurs, à ne pas devenir fous.

Cue la voix de la bande-annonce d'un film à l'ancienne

Dans un monde où le sélecteur "Je sais ce que je fais" existe et où les parties CSS n'existent pas

Plongons dans un monde imaginaire où les parties CSS n'existent pas, et où un sélecteur "Je sais ce que je fais" (appelons-le /deep/ par nostalgie) existe et est "la manière" de le faire. vous êtes censé styliser le modèle DOM interne d'un composant Web racine fantôme.

Et vous avez besoin d'un tel composant pour votre application, alors vous allez télécharger un package npm

npm i some-awesome-package@1.2.3

et ayez le code HTML suivant dans votre application :

<some-awesome-component></some-awesome-component>

Le composant Some Awesome Component contient un div qui est rouge par défaut et n'utilise aucune propriété personnalisée CSS. Et au début, le div rouge va parfaitement bien !

Mais ensuite vous décidez que vous devez changer la couleur du div rouge en rebeccapurple. Alors vous écrivez ce CSS :

@layer my-overides {
  some-awesome-component /deep/ div.the-red-div {
    background: rebeccapurple;
  }
}

the-red-div est un nom terrible pour une classe, mais bon, personne ne se soucie de la structure interne d'un composant Web shadow dom, n'est-ce pas ? Ils ne peuvent pas entrer en conflit avec le monde extérieur, donc les auteurs de composants peuvent écrire des noms de classe terribles s'ils le souhaitent.

Et parce que nous sommes dans notre monde imaginaire où /deep/ existe, tout fonctionne ! Le div rouge est maintenant violet et tout est coolio.

Vous ignorez la petite dissonance cognitive dans notre cerveau selon laquelle .the-red-div a une couleur qui n'est pas rouge. C'est un problème de demain.

Doux !

Ensuite, l'auteur du composant ajoute une fonctionnalité et publie un patch bump.

Vous êtes occupé à expédier et en cours de route, vous avez réinstallé un package sans rapport et vous avez extrait le dernier correctif de Some Awesome Component et le div rouge est de retour !

Ça donne quoi ? Vous allez chercher dans les notes de patch et vous trouvez :

## 1.2.4
- [a987s83] Added cool button, fixed a11y issues

Ça semble bien, pourquoi le CSS s'est-il cassé ? Les notes du journal des modifications ne contiennent aucun indice. Vous parcourez donc les derniers PR et ne voyez rien qui vous saute aux yeux.

Donc, vous lancez votre application et vérifiez la racine fantôme et le div rouge est un maintenant! Et l'auteur du composant s'est rendu compte que son nom de classe, the-red-div, aurait dû être plus générique et l'a changé en coloré.

Ok, très bien, alors vous modifiez votre CSS en :

@layer my-overides {
  some-awesome-component /deep/ .colorful {
    background: rebeccapurple;
  }
}

Et ça fonctionne à nouveau bien !

Puis l'auteur publie un autre patch bump la semaine prochaine.

Retour au monde réel

L'accès direct du sélecteur CSS au DOM que vous ne contrôlez pas est une énorme arme à pied

Vous voyez le modèle et donc le problème d'accès direct du sélecteur aux modèles internes que vous ne possédez pas ou ne contrôlez pas ?

Inévitablement, des modifications seront apportées au modèle interne hors de votre contrôle, le consommateur du composant. Et inévitablement, ces changements se produiront d'une manière qui vous sera presque invisible sans inspecter visuellement CHAQUE PIÈCE de votre application en cours d'exécution, que ce soit manuellement ou avec des outils de test de régression visuelle flous. Si vous utilisez un composant provenant d’Internet, il existe une sorte de contrat. L'auteur du composant est propriétaire du shadow dom et vous, en tant que consommateur, possédez l'élément :host (la balise HTML elle-même dans le code que vous écrivez). Franchir cette frontière sans une sorte de contrat en place est une garantie pour un code fragile.

Fait amusant, cette fragilité se produit également lors de l'exécution directe de requêtes Shadow dom pour les éléments DOM dans JS. Si votre application dépend d’un élément pour toujours exister, ce ne sera pas le cas. Si vous effectuez une requête dans le DOM que vous ne contrôlez pas, un jour, certains éléments ne seront plus là. Soit ce sera un élément différent, soit il aura une classe/attribut/identifiant différent.

Mais les pièces CSS vous soutiennent

Étant donné que les parties CSS sont de simples chaînes qui ne sont pas elles-mêmes des éléments DOM, leur utilisation protège votre application du code fragile. Les auteurs tiers ne vérifieront jamais qu'un div est TOUJOURS un div pour toujours. Mais s'ils créent une partie CSS, ils savent qu'ils créent une API publique pour le composant qui ne peut pas être supprimée ou modifiée sans modification radicale. Et si vous utilisez des parties CSS au lieu d'interroger directement le shadow DOM, l'auteur du composant peut déplacer cette partie CSS dans le shadow dom et le code de votre application ne sera pas interrompu.

De plus, étant donné que les noms de parties CSS impliquent des relations, des concepts et des fonctionnalités, il serait difficile pour un auteur de composant de refactoriser un composant de manière à ce que la partie CSS change considérablement sa signification. Ainsi, en plus de savoir que votre partie CSS utilisant du code ne va pas se briser lorsque l'auteur du composant apporte des modifications sans vous le dire, vous pouvez également être raisonnablement sûr que la partie CSS sera toujours le même genre de chose par rapport à l'ensemble. composant. Ainsi, les styles que vous appliquez à cette pièce seront raisonnablement sûrs d'avoir toujours un sens pour cette pièce, même si le composant évolue au fil du temps.

Un pas de plus

J'ai vu quelques commentaires de gens très intelligents et précieux de l'industrie sur la douleur des pièces CSS et sur le fait que l'ajout d'un accès direct au shadow dom via des sélecteurs serait beaucoup plus pratique. Si rien ne changeait de forme avec le temps, je serais tout à fait d’accord. Mais comme les composants changent au fil du temps, j'oserais supposer que l'accès direct au Shadow DOM sera plus pénible que de devoir se rappeler quelles parties CSS sont disponibles.

Chaque fois qu'il y a des discussions sur la façon de franchir la frontière entre « l'application » et le shadow dom à l'intérieur d'un composant, je préconiserais toujours une approche contractuelle structurelle nommée comme les parties CSS plutôt que l'accès direct au sélecteur. À mon avis, quiconque pense que les parties CSS sont maladroites et terribles n'a tout simplement pas eu à parcourir l'intégralité de son application à la recherche de tous les endroits où un modèle de racine fantôme a changé à son insu :)

Conclusion

Les parties CSS sont géniales et lorsque vous les utilisez, même si vous êtes à 100 % un excellent développeur et que vous savez ce que vous faites, vous ne voulez pas non plus à 100 % avoir à modifier tout ce CSS personnalisé. vous avez écrit à chaque fois qu'il y a un patch sur les composants que vous utilisez. Vous savez certainement ce que vous faites, mais nous voulons tous empêcher nos applications de se briser de manière aléatoire et c'est ce que fera le style DOM direct shadow. Un sélecteur "Je sais ce que je fais" fera certainement fonctionner votre style, mais il ne sera garanti de fonctionner que si vous ne mettez littéralement jamais à jour la version du package que vous avez stylisée. Si vous mettez à jour la version, vous devrez garder un œil sur tous ces styles « Je sais ce que je fais » à chaque fois.

Moi, c'est une perte de notre temps précieux. utilisez simplement les pièces CSS et encouragez les développeurs de composants à les ajouter aux composants qu'ils écrivent.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!