CSS-in-JS , n'étant pas une technologie complètement nouvelle et implémentée dans de nombreuses bibliothèques , soulève toujours des doutes et des débats sur la pertinence de son utilisation. Gajus Kuizinas , l'auteur des modules react -css et babel-plugin , a mis ses points sur le «i» dans les litiges concernant CSS-in-JS en général, et les composants de style en particulier, il y a un an, (27 avr. 2017) -react-css-modules , dans la publication actuelle à mon avis "Arrêtez d'utiliser CSS-in-JavaScript dans le développement web" .
Ce qui suit est une traduction légèrement abrégée avec quelques ajouts et conclusions:
CSS ne va nulle part . Dans de nombreux projets, le choix du style en JavaScript est erroné. Nous allons répertorier les idées fausses courantes (mythes) et leurs décisions correspondantes via CSS.
Histoire de Css et JavaScript
CSS a été créé pour décrire la présentation d'un document écrit dans un langage de balisage. JavaScript a été créé comme un «langage-colle» pour assembler des composants tels que des images et des plugins. Au fil des ans, JS a grandi et changé, s'adaptant à de nouveaux domaines d'application. Et, par conséquent, nous vivons aujourd'hui à l'ère des applications monopages (SPA), des applications assemblées à partir de composants.
Et CSS?
Voici une citation de la documentation des composants de style :
Le problème avec le CSS ordinaire est qu'il a été créé à une époque où le Web était composé de documents. Le Web a été créé pour échanger des documents à prédominance scientifique en 1993 et CSS a été introduit comme solution pour styliser ces documents. Cependant, nous développons aujourd'hui des applications développées, interactives et orientées utilisateur, et CSS n'est tout simplement pas conçu pour cela.
Ce n'est pas le cas.
CSS prend déjà en compte toutes les exigences des interfaces utilisateur modernes. Le nombre de nouvelles fonctions implémentées au cours de la dernière décennie est tel qu'il est impossible de toutes les répertorier (pseudo-classes, pseudo-éléments, variables CSS, requêtes de média, images clés, combinateurs, colonnes, flex, grille, valeurs calculées, ...).
Du point de vue de l'interface utilisateur, «composant» est un fragment isolé du document (<bouton /> est «composant»). CSS est conçu pour styliser les documents et le document couvre tous les composants. Quel est le problème?
Comme dit le proverbe: "Utilisez le bon outil pour le travail."
Composants stylisés
styled-components permet d'écrire du CSS en JavaScript en utilisant ce que l'on appelle chaînes de modèle balisées . La bibliothèque supprime le mappage entre les composants et les styles - le composant se transforme en une construction de style de bas niveau, par exemple:
// Create a <Title> react component that renders an <h1> which is // centered, palevioletred and sized at 1.5em const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `;
styled-components est populaire aujourd'hui et est connu comme une nouvelle façon de styler les composants dans React, bien qu'il soit même parfois présenté comme le «summum du développement CSS»:
Évolution CSS: des modules CSS, SASS, BEM, CSS aux composants stylisés .
Mais clarifions ce qui suit: styled-components n'est qu'un module complémentaire CSS. Cette bibliothèque analyse les styles CSS que vous définissez en JavaScript et crée les éléments JSX appropriés.
La popularité des composants de style est semée de nombreuses idées fausses. Un examen des réponses des programmeurs (trouvés sur IRC, Reddit et Discord) à une question sur les raisons qui les ont poussés à utiliser cette bibliothèque a permis de faire une liste des plus cités. Appelons-les mythes.
Mythe n ° 1: les composants de style résolvent les problèmes d'espace de noms mondiaux et les conflits de style
Il s'agit d'un mythe, car il semble que le problème prétendument mentionné n'a pas encore été résolu. Cependant, les modules CSS , le Shadow DOM et d'innombrables conventions de dénomination (comme BEM ) ont proposé des solutions au problème il y a longtemps.
styled-components (tout comme les modules CSS) supprime le problème de la responsabilité des noms d'une personne. C'est la nature humaine de faire des erreurs; les ordinateurs font des erreurs moins souvent.
En soi, ce n'est pas une raison suffisante pour utiliser des composants de style.
Mythe 2: L'utilisation de composants de style permet d'obtenir un code plus compact.
À l'appui de cela, donnez souvent un exemple:
<TicketName></TicketName> <div className={styles.ticketName}></div>
Tout d'abord, cela n'a pas d'importance. La différence est négligeable.
Deuxièmement, ce n'est pas vrai. Le nombre total de caractères dépend du nom du style.
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
La même chose s'applique à la création de styles, que nous verrons plus loin dans cet article.
(Mythe 5: les composants stylisés facilitent le style conditionnel des composants). styled-components ne gagne en brièveté que dans les cas des composants les plus basiques.
Mythe 3. L'utilisation de composants stylisés vous fait réfléchir davantage sur la sémantique.
Le message d'origine lui-même est erroné. La stylisation et la sémantique sont des problèmes différents et nécessitent des solutions différentes. Lisez, par exemple, c'est Adam Morse (mrmrs) .
Cependant, considérez:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
La sémantique traite de l'utilisation des balises correctes pour le balisage. Savez-vous quelles balises HTML seront utilisées pour rendre un tel composant? Non, tu ne sais pas.
Comparez:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
Mythe 4: il est plus facile d'étendre les styles.
Comparez:
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
Super! Mais vous pouvez faire la même chose en CSS (ou utiliser la composition du module CSS, ainsi que le mixage d'héritage SASS @extend).
button { padding: 10px; } button.tomato-button { color: #f00; }
Et le plus simple est la première option?
Mythe 5: style conditionnel facilité des composants
L'idée est que vous pouvez styliser des éléments à l'aide d'accessoires, par exemple:
<Button primary /> <Button secondary /> <Button primary active={true} />
Cela a du sens dans React. Au final, le comportement des composants est contrôlé par des accessoires. Est-il judicieux de lier directement les valeurs des accessoires aux styles? Peut-être. Mais regardons la mise en œuvre d'un tel composant:
styled.Button` background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'}; color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'}; opacity: ${props => props.active ? 1 : 0}; `;
La création de styles conditionnels à l'aide de JavaScript offre une tonne de possibilités. Cependant, cela signifie également que les styles seront beaucoup plus difficiles à interpréter. Comparez avec CSS:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
Dans ce cas, CSS est plus court (229 caractères contre 222) et plus facile à comprendre (subjectivement). De plus, en CSS, vous pouvez utiliser un préprocesseur pour obtenir un résultat encore plus court et groupé:
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
Mythe 6: l'organisation du code s'améliore
Certains disent qu'ils aiment les composants de style, car il devient possible de placer des styles et des scripts dans un seul fichier. Vous pouvez comprendre que le fait d'avoir plusieurs fichiers pour un composant peut sembler fastidieux, mais enfoncer les styles et la mise en page dans un seul fichier est terrible. Non seulement ce système de contrôle de version compliquera le suivi des modifications, mais il entraînera également un «défilement» sans fin sur tout élément plus compliqué qu'un simple bouton.
Si vous devez certainement mettre CSS et JavaScript dans le même fichier, essayez css-literal-loader . Ce dernier vous permet de créer des styles lors de la construction en utilisant extract-text-webpack-plugin et d'utiliser la configuration de chargeur standard pour gérer CSS.
Mythe 7: «Developer Experience (DX)» devient grand. L'outil est génial!
De toute évidence, vous n'avez pas utilisé de composants de style.
- En cas de problème avec les styles, l'application entière se bloque avec une longue trace de pile de l'erreur. Le contraire est CSS, où une erreur dans les styles entraînera simplement un affichage incorrect de l'élément.
- Les éléments n'ont pas de nom de classe distinct, donc pendant le débogage, vous devrez basculer sans fin entre l'arborescence des éléments React et l'arborescence DOM DevTools.
- Bien que des plugins pour le linting, la mise en évidence du code, l'achèvement du code et d'autres «charmes» similaires existent déjà pour les composants de style, ils peuvent ne pas être disponibles pour votre IDE. Si vous travaillez avec des finances dans une agence gouvernementale, il est possible que l'Atome IDE ne soit pas disponible.
Mythe 8: Tout devient «plus rapide», tout devient «plus facile»
- Il s'est avéré que les styles de composants de style ne peuvent pas être extraits en statique
Fichier CSS (par exemple en utilisant extract-text-webpack-plugin ). Cela signifie que le navigateur ne pourra pas commencer à interpréter les styles jusqu'à ce que les composants stylisés les analysent et les ajoutent au DOM. - La combinaison de styles et de scripts dans un fichier signifie que la mise en cache séparée n'est pas possible.
- La nature des composants de style est telle qu'ils sont tous enveloppés dans du HOC supplémentaire. Et c'est une diminution inutile des performances. Le même défaut a conduit à l'arrêt des modules react-css et à l'apparition des modules babel-plugin-react-css-modules .
- En raison du même HOC , le rendu côté serveur se traduit par des tailles de balisage de document beaucoup plus grandes.
- N'essayez même pas d'animer des composants à l'aide de styles dynamiques plutôt que d'images clés.
Mythe 9: Il est possible de développer des composants "réactifs"
Nous parlons de la possibilité de styliser un composant en fonction de l'environnement, par exemple, la taille du conteneur parent, le nombre d'héritiers, etc.
Tout d'abord, les composants de style n'ont rien à voir avec cela.
Cela dépasse la portée du projet. Dans ce cas, il est préférable de définir directement les valeurs de style de composant afin d'éviter des charges de processeur supplémentaires.
Attendez une minute, cependant!
La plupart, sinon la totalité de ces problèmes peuvent être résolus à long terme soit par la communauté, par des modifications dans React ou dans les composants de style eux-mêmes. Mais pourquoi? CSS est déjà largement pris en charge, il existe une communauté solide et ... cela fonctionne.
Mais vous ne devez pas toujours éviter d'utiliser CSS-en-JavaScript ou des composants de style.
Il y a quelque chose qui fait des composants de style une bonne bibliothèque - c'est le meilleur support multiplateforme.
N'utilisez simplement pas de composants de style basés sur des représentations erronées.
Une paire d'opinions de parties intéressées.
En utilisant des composants stylisés dans notre projet, nous avons constaté qu'il existe des règles de style difficiles à implémenter dans les composants stylisés; par exemple, des règles qui contrôlent le placement des éléments sur une page (marges ou propriété d'affichage). Il était difficile de standardiser, donc nous devions encore compter fortement sur du CSS simple pour placer des composants dans le flux d'éléments.
... bien qu'il y ait eu des difficultés à utiliser des composants de style, la bibliothèque nous a aidés à réduire la base de code.
(commentaire sur «L'évolution des CSS: des CSS, SASS, BEM et CSS - modules aux composants stylisés» )
... Aucune évolution du CSS ici ne signifie que les outils évoluent.
À mon avis, il n'y a aucun problème lorsque la composition est engagée dans la mise en page et que le programmeur est engagé dans la programmation.
Mais lorsque les programmeurs sont engagés dans la composition, alors tout ce zoo commence, ce qui au lieu de SIMPLICITY avec un support supplémentaire, donne un mal de tête supplémentaire.
...
Écrivez en pur CSS et donnez aux outils le rôle d'un espace de noms et d'un collecteur - alors tout sera heureux ...
Et enfin, un mot à l'auteur:
Gajus Kuizinas: - Alors quoi, après tout, utiliser?