Récemment, Facebook (propriété de Meta) a publié sa propre bibliothèque CSS-in-JS appelée StyleX. Selon les développeurs, il est idéal pour les grands projets et son principal avantage réside dans les performances. Il est prévu que StyleX soit désormais promu comme meilleure pratique pour les projets React.
Les avantages revendiqués de l’utilisation de StyleX sont la réutilisation, la typification, et tout ira bien sur les grands projets. Eh bien, j’obtiens enfin un fichier complet « Single File Component » avec JS, CSS et HTML dans une seule bouteille.
Avantages clés
Les développeurs de la bibliothèque déclarent plusieurs avantages :
- Performance – la bibliothèque au stade de la compilation utilisant le plugin Babel transforme JS en un seul fichier CSS optimisé en taille, nous évitons ainsi les problèmes d’exécution classiques CSS-in-JS.
- Évolutivité – l’ingénieux plugin Babel utilise la mise en cache au niveau des fichiers et génère des noms de classes atomiques, ce qui minimise la taille du bundle, et l’augmentation du nombre de composants dans l’application n’affecte pas beaucoup la taille du fichier CSS.
- Prévisibilité – La priorisation des sélecteurs dans StyleX est très simple – le dernier style spécifié gagne toujours. Cela signifie que vous pouvez oublier la cascade.
- Combinabilité – les objets de style peuvent être exportés et transmis aux composants. Dans ce cas, les styles se comporteront toujours de manière prévisible.
- Dactylographie – Chaque propriété et variable CSS est entièrement typée et nous pouvons utiliser TypeScript ou Flow pour définir les styles transmis au composant.
- Tout en un seul endroit – la bibliothèque encourage la définition de styles dans le même fichier que le composant, un petit fichier sur plusieurs fichiers plus petits. Avec cette approche, StyleX supprime les propriétés inutilisées du bundle et supprime les doublons.
Entre autres fonctionnalités, nous avons :
- Résolution déterministe
- Abstractions à faible coût
- Petite surface API
- Styles de type sécurisé
- Constantes partageables
- Indépendant du framework
- Encapsulation
- Lisibilité et maintenabilité
- Modularité et composabilité
- Évitez la configuration globale
Voici comment Facebook justifie les raisons de la création de StyleX :
L’ancien site Facebook utilisait quelque chose de similaire aux modules CSS et souffrait de divers problèmes qui ont inspiré la création de CSS-in-JS. Le visiteur moyen de Facebook.com devait télécharger des dizaines de mégaoctets de CSS, dont la plupart n’étaient pas utilisés. Pour optimiser le chargement initial, nous avons chargé paresseusement notre CSS, ce qui a entraîné un rafraîchissement lent (ou « Interaction avec la peinture suivante »). L’utilisation de sélecteurs complexes a conduit à des conflits ou à des « guerres de spécificité » entre sélecteurs. Les ingénieurs ont souvent eu recours à
!important
ou des sélecteurs plus complexes pour résoudre leurs problèmes, aggravant progressivement l’ensemble du système.Il y a quelques années, lorsque nous reconstruisions Facebook.com à partir de zéro à l’aide de React, nous avons réalisé que nous avions besoin de quelque chose de mieux et avons créé StyleX.
StyleX a été conçu à grande échelle et sa conception a prouvé son efficacité au fil des années d’utilisation. Nous avons ajouté de nouvelles fonctionnalités à StyleX sans sacrifier les performances ou l’évolutivité, rendant StyleX encore plus agréable à utiliser.
L’utilisation de StyleX a constitué une amélioration significative pour nous chez Meta, à la fois en termes d’évolutivité et d’expressivité. Sur Facebook.com, nous avons pu réduire le nombre de packages CSS de plusieurs dizaines de mégaoctets de CSS chargés paresseusement à un seul package de quelques centaines de kilo-octets. Nous avons créé StyleX non seulement pour répondre aux besoins de style des développeurs React sur le Web, mais également pour unifier le style de React sur le Web et en mode natif.
StyleX est un cadre indépendant. Cela signifie que la bibliothèque peut être utilisée avec n’importe quel framework JS : React, Angular, vous l’appelez. Cependant, pour ceux qui utilisent des extensions de fichiers personnalisées, telles que Svelte et Vue, cela peut nécessiter une configuration supplémentaire.
Jetons un coup d’œil à un exemple d’utilisation et aux principales fonctionnalités de ce framework. Le code ressemble à :
import {Button} from ". /Button" import * as stylex from "@stylexjs/stylex" const .styles = stylex.create({ heading: { color: "red", }, button: { margin: 20px, } }) export default function App() { return ( <> <h1 { ... stylex.props(styles.heading)}>Heading</h1> <Button styles={styles.button}>Button</Button> <> ) }
Par rapport à Tailwind, nous avons accès à des types intégrés qui nous permettent de définir clairement les propriétés qui peuvent être remplacées. Il n’est pas nécessaire de créer un accessoire distinct pour chaque propriété.
Critique
Désireux d’éliminer la priorité des sélecteurs, StyleX éloigne les développeurs de la nature en cascade du CSS, ainsi que d’une large gamme de ses fonctionnalités intégrées. Cela donne l’impression qu’une paire HTML + CSS est considérée comme complexe pour un développeur de masse, nous obtenons donc à la place JSX avec plusieurs frameworks CSS.
Pour les sites simples, vous n’avez pas besoin de rendre les choses trop complexes et vous pouvez vous débrouiller avec du HTML et du CSS purs. Le CSS moderne est suffisamment mature et prend en charge nativement une grille réactive avec un code mineur, pour ceux qui en ont besoin.
Lorsque vous recherchez un problème spécifique, vous trouverez la recette de la solution en CSS pur, et non en StyleX, car la communauté CSS est plus large que celle d’une bibliothèque qui vient de sortir. Cela signifie que vous devez le « traduire » en StyleX pour tester avec votre code, et d’autres manières – lorsque vous rencontrez des problèmes avec les styles, vous devrez le traduire en CSS brut pour le demander quelque part comme StackOverflow.
Enfin, StyleX est une autre dépendance pour Webpack, qui s’ajoute.
Conclusion
Malgré les critiques, je pense que ce cadre sera vraiment utile sur les grands projets lors de la création de systèmes de conception complexes utilisés par de nombreuses équipes. Facebook a testé et affiné son produit pendant trois ans avant de le publier en open source. Il me semble que c’est une raison suffisante pour croire que la bibliothèque est testée et peut être utilisée dans des projets réels.
Source link