web-dev-qa-db-fra.com

Composant stylé vs SASS (SCSS) ou MOINS

Je suis tombé sur une chaudière ReactJS qui avait de bons représentants et est dirigée par la communauté. La section de style met davantage l'accent sur le style CSS des composants, mais n'a jamais cessé de passer aux méthodologies de style CSS conventionnelles. Bien que cela ait attiré mon intérêt, ce qui fait que le CSS Styled-Component se démarque et pourquoi faut-il l'adopter.

Ma compréhension de Composant stylisé CSS :

  1. Identité pilotée par les composants. Votre CSS est également désormais un composant. - C'est plutôt cool!
  2. Chargez ce dont vous avez besoin et quand vous en avez besoin, CSS un peu paresseux
  3. Fournisseur de thèmes, skins, modularité et dynamique - Ceci peut également être réalisé par d'autres bibliothèques
  4. Construction côté serveur de votre composant DOM et son style.

Mes questions sont:

  1. Les navigateurs ont évolué pour analyser CSS séparément de l'analyse Javascript, pourquoi essayons-nous de nous en écarter et de les adapter à Javascript?

  2. Le CSS à composant stylisé expédie sa bibliothèque javascript à l'extrémité cliente, qui analyse en fait les styles au moment de l'exécution et les place à l'intérieur de <style /> tag lorsque chaque composant se charge à la demande. Cela signifie une charge supplémentaire et une logique contribuant éventuellement aux cycles d'exécution sur le navigateur. Pourquoi en avoir besoin?

    (Par la question ci-dessus, je veux dire que pour chaque composant, le CSS correspondant est calculé et créé et inséré dans head via style tag/Plusieurs balises de style - Réinventer les interpréteurs CSS)

  3. Est-ce que le texte de style calculé en continu frappe par <style /> dans la balise head provoque une refusion/repeinture du navigateur?

  4. Quels sont les avantages en termes de performances que j'en retire?

Communauté, nettoyez l'air pour moi ou corrigez-moi si je me trompe.

Quelques bons articles qui parlent de repeindre ou de redistribuer DOM comment les performances sont coûteuses pour le navigateur lorsque les styles CSS sont modifiés.

cssreactjssassstyled-componentsreflow
20
Nirus

Les navigateurs ont évolué pour analyser CSS séparément de l'analyse Javascript, pourquoi essayons-nous de nous en écarter et de les adapter à Javascript?

Lorsque vous mélangez Javascript et HTML (à savoir JSX) puis CSS (JSS ou autre), vous faites de votre composant un module solide qui tient dans un seul fichier. Vous n'avez plus besoin de conserver les styles dans un fichier séparé.

Ensuite, la magie fonctionnelle se produit: comme JSX est une fonction pure de données brutes qui retourne "HTML" (pas vraiment), de la même manière que CSS-in-JS est une fonction pure ou des données brutes qui retourne "CSS" (également pas vraiment ). À partir de ce point, je pense que cela vaut la peine lire sur JSX et également sur CSS-in-JS .

Le CSS à composant stylisé expédie sa bibliothèque javascript à l'extrémité cliente, qui analyse en fait les styles au moment de l'exécution et les place à l'intérieur de <style /> tag lorsque chaque composant se charge à la demande. Cela signifie une charge supplémentaire et une logique contribuant éventuellement aux cycles d'exécution sur le navigateur.

Pas seulement sur l'exécution. Parce que CSS-in-JSS n'est qu'une fonction des données qui renvoient CSS, vous pouvez l'utiliser sur n'importe quelle plate-forme. Prenez Node, ajoutez SSR , et vous avez style éléments livrés au navigateur dans le corps de la réponse, donc analysés comme cela se produirait dans le cas d'origine de la livraison CSS.

Pourquoi en avoir besoin?

Parce qu'il est pratique en développement, tout comme React ou Redux, tout comme jQuery, et comme toute autre bibliothèque, il a un coût de charge réseau et de performances du navigateur.

Vous prenez une bibliothèque car elle résout un problème. S'il ne semble pas y avoir de problème, pourquoi utiliser la bibliothèque, n'est-ce pas?

Est-ce que le texte de style calculé en continu frappe par <style /> dans la balise head provoque une refusion/repeinture du navigateur?

Il y a tant de choses qui forcent la refusion .

Les navigateurs sont intelligents. Ils ne tentent même pas de repeindre si les styles n'ont pas changé. Ce qui ne veut pas dire qu'ils ne calculent pas la différence, ce qui coûte du temps CPU.

Il y a une bonne introduction à la portée et la complexité des (re) calculs de style , cela vaut vraiment la peine d'être lu pour comprendre le sujet plus en profondeur.

1
Fleischpflanzerl

J'utilise SCSS (SASS) depuis de nombreuses années et j'utilise également Styled-Components pour quelques projets, certains de grande envergure.

J'adore les deux, et Styled-Components me semble être un pas en avant:

Composants stylisés - Avantages

  1. Isolation totale du style; empêche les bogues potentiels lors du travail en équipe, lorsqu'un membre de l'équipe ne peut jamais remplacer un style d'un autre.
  2. Suppression de la nécessité de gérer manuellement les noms de classe lors de leur génération automatique

  3. J'ai trouvé plus facile de travailler avec [~ # ~] css [~ # ~] dans le [ ~ # ~] jsx [~ # ~] fichier lui-même (j'étais contre cette idée pendant de nombreuses années)

  4. Possibilité d'utiliser facilement des variables javascript dans les styles

Composants stylisés - Inconvénients

  1. Chaque composant de style est encore une autre fonction d'encapsuleur, et de nombreux composants de style signifient plus de fonctions, ce qui signifie moins efficace car tout ce code doit être "compilé" et ainsi de suite.
  2. Le plus gros inconvénient: les changements de styles nécessitent une recompilation du bundle et l'état de l'application peut être réinitialisé.

Les inconvénients ne peuvent être vus comme tels que sur certains scénarios mais pas nécessairement tous.

SCSS/LESS les avantages peuvent être considérés comme opposés aux inconvénients énumérés ci-dessus, tout en ayant des inconvénients supplémentaires tels que les mélanges et un développement plus rapide lorsque vous travaillez avec des variables (IMHO ). il peut devenir "moche" en définissant une variable de sélection locale:

Comparez ces exemples simplifiés:

SCSS exemple:

.icon{
  $size: '20px';
  width: $size;
  height: $size;
  margin-left: $size/2;
}

Styled-Components exemple de portée locale:

const Icon = styled.i(props => {
  const size = 20; // easier to use Number instead of String for calculations 
  return `
    width: ${size}px;
    height: ${size}px;
    margin-left: ${size/2}px;
`});

Évidemment, la variable aurait pu être définie en dehors de l'encapsuleur de style Icon puis utilisée en interne, mais cela ne la rendra pas isolée, car les composants CSS de style peuvent être composés de sous-composants de style et ressembler davantage à CSS :

const Header = styled.header`
   > ul{
     ...
   }

   li{
     ...
   }

   img{...}

   navigation{...}
`

Il n'est pas toujours souhaitable d'extraire chaque élément HTML individuel de son propre composant de style . cela se fait principalement pour les composants qui sont ou pourraient être répétés dans l'application.

En ce qui concerne les mélanges SASS, ils peuvent être convertis en fonctions javascript, donc il n'y a pas beaucoup d'avantages à SASS ici.

Dans l'ensemble, travailler avec des composants stylisés est amusant et facile, mais a pour effet secondaire un couplage plus étroit entre les styles et le cadre/composant et il a évidemment une certaine pénalité de performance (rien qui ne vous ralentira réellement, mais quand même) .

0
vsync