Ce message est une réponse détaillée aux questions de cette conversation sur Twitter . L'auteur de l'original, Sunil Pye, est l'auteur de la bibliothèque glamour relativement populaire et travaille en tant que développeur sur Facebook.
En quoi Javascript est-il plus pratique que CSS? Comment l'écriture CSS dans JS le rend-elle plus supportée?
Je serai heureux de parler de ce sujet. Je dois dire tout de suite que les solutions CSS-in-JS ont des frais généraux, mais généralement ce prix est justifié par les avantages qu'elles apportent. Parfois, ils peuvent être utiles, mais cela ne signifie pas non plus que CSS-in-JS doit être utilisé partout et toujours.
Ainsi, la chose la plus importante dans CSS-in-JS (cij) est les sélecteurs CSS. Le plus grand avantage de cij est que les ordinateurs peuvent générer ces sélecteurs automatiquement. Conventions telles que OOCSS, etc. en principe, ils sont bons, mais ils sont basés sur des sélecteurs écrits manuellement, qui sont difficiles à garantir l'unicité dans l'espace de noms commun, car il y a toujours une chance d'intersection. Si cela ne se produit pas maintenant, cela peut arriver après trois ans, lorsque votre équipe s'agrandit et que les circonstances changent. Cette situation est exacerbée à l'aide de bibliothèques tierces. Il est également possible de limiter la portée des sélecteurs CSS en utilisant des modules CSS , qui sont populaires précisément pour cette opportunité.
Néanmoins, avec toutes ces approches, les sélecteurs sont très difficiles à analyser statiquement et à trouver ceux qui sont cassés (ou contiennent des fautes de frappe), ce qui signifie qu'ils devront être vérifiés manuellement dans le processus de révision du code, ce qui réduira l'efficacité de la commande. Nous devons utiliser l'aide d'ordinateurs et ne pas compter sur l'intégrité et la perfection des gens (car ce n'est pas le cas). CSS-in-JS permet d'automatiser la génération de sélecteurs et d'identifiants uniques.
De plus, un contrôle amélioré des sélecteurs CSS ouvre de nouvelles possibilités qui n'étaient pas facilement accessibles auparavant. Par exemple, nous pouvons simplement implémenter l'extraction CSS critique en faisant correspondre les blocs HTML avec les styles dont ils ont besoin, de sorte que nous ne pouvons charger que 1-2 Ko de CSS sur la page, ce qui est nécessaire pour l'affichage initial de la page. Sans aucun runtime! Des cadres tels que Gatsby et Next l' utilisent activement pour améliorer les indicateurs de performance dans les projets basés sur eux. Ils intègrent le CSS critique directement dans le HTML téléchargeable simplement parce qu'il pèse si peu qu'il serait préférable à une demande supplémentaire bloquant le chargement de la page. Cela réduit considérablement le temps de rendu de page initial. De plus, il contribue également à résoudre les problèmes de taille Javascript téléchargeable! Les avantages proviennent de l'application de CSS critiques, ainsi que de l'utilisation de l' import() dynamique import() , du fractionnement du code et de la suppression du code inutilisé. (Contrairement aux fichiers de style Legacy en constante évolution, dans lesquels les développeurs ajoutent uniquement du nouveau code, ayant peur de toucher à celui existant. Il y a un peu d'analyse sur ce sujet .)
Une situation similaire avec la mise en œuvre des thèmes. Saviez-vous que les variables CSS , même étant une chose très intéressante, n'ont pas décollé pour les cas d'utilisation auxquels elles étaient initialement destinées, et tout cela parce que les méthodes de secours pour les anciens navigateurs étaient soit très compliquées soit inférieures? Cela signifie qu'elles sont généralement utilisées comme constantes globales, mais très rarement comme variables dont la valeur est déterminée dynamiquement dans le navigateur. Avoir un runtime CSS CSS signifie que vous pouvez passer des valeurs de JS aux styles, ce qui rend cela possible.
En fait, vous l'aimerez: vous pouvez enfin honnêtement utiliser des variables CSS dans tous les navigateurs, c'est-à-dire des capacités natives sans exécution dans les navigateurs qui les prennent en charge, et une exécution spéciale pour les anciens navigateurs. (J'ai écrit plus à ce sujet ici , et - si je comprends bien - c'est la seule bibliothèque qui a atteint cet objectif).
Dans une situation SPA complexe avec un tas de composants et un chargement asynchrone de ressources, tels que des scripts et des styles, vous ne pouvez pas garantir l'ordre exact de chargement des styles, vous devez donc créer une sorte de solutions d'exécution pour garantir l'ordre des styles, ou simplement utiliser !important , même si vous vous en tenez à une sorte de méthodologie CSS . Par exemple, vous avez un élément avec class=“ab” , mais les classes a et b définies dans des fichiers de style différents, alors vous ne pouvez pas être sûr de la forme finale du bloc si vous n'avez pas un ordre de séquence clair des fichiers de style. La base de code Facebook contient des milliers d'utilisations de !important , même si le code a été écrit par des programmeurs qualifiés en utilisant des principes SOLIDES et une bonne interaction avec l'équipe de conception.
Cela fait souvent référence à la manipulation de CSS comme s'il s'agissait de Javascript - étant donné qu'il y a 10 ans, nous résolvions déjà des problèmes similaires pour JS - les bibliothèques et les modules se sont enregistrés dans l'espace de noms global ( $ et autres) et nous avons dû être très prudents avec l'ordre de connexion. scripts en HTML. Mais nous n'étions pas coincés là pour toujours - nous utilisons maintenant des modules et les systèmes d'assemblage les cousent ensemble dans un ordre correct garanti. C'est simple et transparent pour nous.
En regardant de vrais projets, j'ai également remarqué que vous pouvez toujours utiliser des approches architecturales traditionnelles (telles que OOCSS ou SMACSS, etc.) dans le monde CSS-in-JS - les éléments de ces architectures sont représentés ici par des objets JS, au lieu des blocs de sélection + styles. Je prends cette approche et cela fonctionne bien pour moi. Ici vous pouvez en savoir plus.
Je connais également bien les inconvénients de CSS-in-JS. En fait, c'est précisément pourquoi il n'y a pas une seule bibliothèque «canonique» qui représente CSS-in-JS - c'est un spectre de solutions différentes, du CSS statique vanille d'une part aux bibliothèques entièrement dynamiques comme les composants de style de l'autre. Les préprocesseurs tels que SASS ou LESS peuvent sembler perpendiculaires à ce spectre, car ils peuvent théoriquement être utilisés par n'importe laquelle de ces bibliothèques à la discrétion de leurs auteurs. Chacune de ces bibliothèques a ses inconvénients - certaines sont engagées dans l'extraction de styles au stade de l'assemblage afin qu'il n'y ait pas de coûts d'exécution, certaines sont axées sur l'exactitude ou la commodité pour les développeurs, d'autres se concentrent sur la mise en œuvre efficace d'animations complexes, etc., etc. Cette diversité est une réaction naturelle au besoin de solutions différentes pour différentes tâches, dans une industrie à croissance trop rapide. Et cela se produit non seulement avec les bibliothèques - les développeurs de normes Web (ShadowDOM et autres) tentent vaillamment de résoudre ces problèmes aussi, mais leur solution a également des inconvénients, le moins étant qu'ils ne sont pas encore disponibles partout, ce qui rend leur utilisation inacceptable. dans de nombreuses équipes.
J'avais de forts sentiments à ce sujet, mais j'ai tempéré mes opinions au cours des derniers mois. Il s'avère que la vérité se situe en fait quelque part au milieu - cela dépend des équipes, des exigences, du temps, de la documentation et de nombreux autres facteurs. De plus, je ne pense pas que ce texte représente la «forme finale» de cette idée. Nous devons encourager l'expérimentation dans ce domaine afin de découvrir ce que nous pouvons faire de mieux et même d'intégrer certaines de ces choses dans les navigateurs.
PS Trop tard, j'ai réalisé que j'avais oublié de cocher la case "Traduction", donc ça a été publié comme ça. Lien vers l'original .
Habr, corrige l'interface, pourquoi ne pouvez-vous pas ajouter l'indicateur de traduction après la publication?