The Codest
  • A propos de nous
  • Services
    • Développement de logiciels
      • Développement frontal
      • Développement backend
    • Staff Augmentation
      • Développeurs frontaux
      • Développeurs backend
      • Ingénieurs des données
      • Ingénieurs en informatique dématérialisée
      • Ingénieurs AQ
      • Autres
    • Conseil consultatif
      • Audit et conseil
  • Industries
    • Fintech et banque
    • E-commerce
    • Adtech
    • Santé (Healthtech)
    • Fabrication
    • Logistique
    • Automobile
    • IOT
  • Valeur pour
    • CEO
    • CTO
    • Gestionnaire des livraisons
  • Notre équipe
  • Études de cas
  • Savoir comment
    • Blog
    • Rencontres
    • Webinaires
    • Ressources
Carrières Prendre contact
  • A propos de nous
  • Services
    • Développement de logiciels
      • Développement frontal
      • Développement backend
    • Staff Augmentation
      • Développeurs frontaux
      • Développeurs backend
      • Ingénieurs des données
      • Ingénieurs en informatique dématérialisée
      • Ingénieurs AQ
      • Autres
    • Conseil consultatif
      • Audit et conseil
  • Valeur pour
    • CEO
    • CTO
    • Gestionnaire des livraisons
  • Notre équipe
  • Études de cas
  • Savoir comment
    • Blog
    • Rencontres
    • Webinaires
    • Ressources
Carrières Prendre contact
Flèche arrière RETOUR
2021-10-05
Développement de logiciels

Pourquoi utiliser SCSS plutôt que des composants stylisés ?

The Codest

Jacek Ludzik

Concepteur de produits

Depuis quelques mois, je travaille sur un projet pour l'un de nos clients. Au tout début, j'ai été confronté à un choix de bibliothèque pour le stylisme.

Après avoir comparé les solutions les plus courantes, telles que CSS, Emotion, SCSS et Composants stylisésJ'ai finalement choisi le dernier. Tout semblait aller pour le mieux. Il dispose d'une bibliothèque très populaire de nos jours, ce qui signifie que
il y a déjà une grande communauté, donc si je rencontre un problème, je trouverai probablement une solution quelque part sur Stack Overflow ou GitHub. En plus de cela, Composants stylisés sont dotés de fonctions d'optimisation, ce qui signifie qu'ils ne s'affichent que lorsqu'ils sont nécessaires. Les projet devait être construit en utilisant React et Typescript. Cette bibliothèque supporte parfaitement ces deux technologies. Ça a l'air génial, non ?

J'ai commencé à coder à ce moment-là. Au bout d'un mois, lorsque l'application a grandi, le frontend a été modifié. équipe et moi sur la livraison de fonctionnalités, nous avons découvert que l'incroyable Composants stylisés La bibliothèque avait son propre objectif et je vais vous dire pourquoi.

Tout d'abord, la convention d'appellation. Pour différencier les Composants stylisés à partir de composants React, j'ai dû utiliser les Stylé préfixe qui a diminué code lisibilité. Puis (ce qui peut paraître étrange), le support de Typescript. Composants styliséscomme vous le savez peut-être, sont basés sur l'approche CSS-in-JS. Cela signifie que vous pouvez leur passer n'importe quelle propriété et changer le style de, c'est-à-dire, l'entrée basée sur cette propriété et je pense personnellement que cette fonctionnalité est géniale. En Typescript, vous devez également implémenter le type de cette propriété, ce qui rend le code plus long que n'importe quel autre type de code. Composant stylé. "Mais cela prendrait 5 secondes de plus, alors quel est le problème ? Vous avez raison, même si lorsque l'application s'étend rapidement et que le nombre de composants est
Ces 5 secondes peuvent être facilement multipliées par des centaines de fois. Un autre problème est l'emplacement du Composants stylisés.

Certains Développeurs JS les placent dans le même fichier que le composant auquel ils appartiennent, tandis que d'autres créent des fichiers distincts pour eux. Les deux approches sont bonnes pour de nombreuses raisons. Elles dépendent principalement de la complexité du composant. Suivre l'une de ces techniques peut maintenir la cohésion, mais les fusionner donne exactement le contraire. Nous avons abandonné l'approche CSS-in-JS et avons migré vers SCSS. Cela n'a pas été facile et rapide, mais avec un peu d'aide, nous y sommes parvenus. Nous avons commencé à styliser les balises html selon la méthodologie BEM et, bien sûr, nous avons placé les styles dans des fichiers séparés, un par composant. J'ai dit que passer des props JS à Composants stylisés est une fonction géniale, mais dans SCSS c'est impossible. Je pense que nous sommes tous d'accord pour dire que la syntaxe que React veut utiliser pour coder les classes conditionnelles est horrible.

code des noms de classe react

Il existe une solution très intéressante. Si vous reliez la méthodologie BEM à la méthode clsx vous obtiendrez quelque chose comme ceci (un grand merci à mon ami Przemek Adamczyk pour m'avoir montré cette bibliothèque)

code clsx

C'est beaucoup plus propre, vous ne trouvez pas ?

L'avantage est que vous n'avez qu'à saisir la variable de condition au niveau du composant et que vous n'avez qu'à la saisir au niveau du composant.
pas au niveau du style. C'est un véritable gain de temps. Malheureusement, cette solution a ses inconvénients.
SCSS est facile et convivial, mais soyez prudent lorsque vous l'utilisez avec Next.js. Ce framework ne
permettent d'importer des fichiers de style directement dans le fichier du composant (uniquement pour les modules CSS).

Si vous préférez un fichier par composant, vous devez créer index.scss contenant tous vos SCSS et
l'importer dans le App.tsx fichier. Le seul problème est que vous devez importer manuellement chaque SCSS que vous avez créé. Dans React, cependant, ce problème n'existe pas et vous pouvez importer SCSS où vous le souhaitez. Ne vous méprenez pas. Composants stylisés sont vraiment bonnes. Comme je l'ai déjà dit, le passage de variables JS ainsi que le thème global sont des fonctionnalités étonnantes. Lorsque vous construisez une grosse application où l'optimisation est cruciale, cette bibliothèque répondra probablement à vos besoins. Dans notre cas cependant, la migration vers SCSS a décroché le jackpot.

Résumé

En conclusion, bien qu'il y ait des arguments valables en faveur de l'un et de l'autre SCSS et composants stylisés en développement web La décision finale dépend de plusieurs facteurs. SCSS offre une syntaxe plus familière pour développeurs expérimentés dans les feuilles de calcul traditionnelles et s'intègre parfaitement dans les systèmes d'information existants. bases de code et bibliothèques de composants .

D'autre part, Composants stylisés offrir des services améliorés expérience des développeurs grâce à sa capacité à encapsuler les styles dans les composants et à simplifier le processus de stylisation. Il favorise également la modularité et la réutilisation du code, ce qui permet aux ingénieurs frontaux de gérer efficacement le processus de création de contenu. répertoire des composants et créer une interface utilisateur cohérente dans l'ensemble du application web . Compte tenu de l'importance des données de l'utilisateur Pour des raisons de sécurité et de performance, il est essentiel d'évaluer l'impact des deux approches sur la taille finale du paquet et les temps de chargement. En fin de compte, le choix entre SCSS et composants stylisés doit se fonder sur les besoins spécifiques du projet, sur les compétences de l'équipe de projet et sur les besoins de l'équipe de projet. équipe de développement et les objectifs généraux de la application web . Il est conseillé aux développeurs d'évaluer tous les facteurs, de se tenir au courant par le biais d'un site web. articles de blog et les discussions de l'industrie, et prendre une décision éclairée qui s'aligne sur les exigences de leur projet et améliore l'ensemble de la stratégie de l'entreprise. processus de développement du front-end .

Articles connexes

Développement de logiciels

La comparaison des champions : Angular vs Vue

Actuellement, il existe quelques frameworks frontaux couramment utilisés et constamment développés par leurs créateurs, tous légèrement différents les uns des autres. Et pourtant, ils peuvent avoir quelque chose en commun. Voici...

Oliwia Oremek

Abonnez-vous à notre base de connaissances et restez au courant de l'expertise du secteur des technologies de l'information.

    A propos de nous

    The Codest - Entreprise internationale de développement de logiciels avec des centres technologiques en Pologne.

    Royaume-Uni - Siège

    • Bureau 303B, 182-184 High Street North E6 2JA
      Londres, Angleterre

    Pologne - Les pôles technologiques locaux

    • Parc de bureaux Fabryczna, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Varsovie, Pologne

      The Codest

    • Accueil
    • A propos de nous
    • Services
    • Études de cas
    • Savoir comment
    • Carrières
    • Dictionnaire

      Services

    • Conseil consultatif
    • Développement de logiciels
    • Développement backend
    • Développement frontal
    • Staff Augmentation
    • Développeurs backend
    • Ingénieurs en informatique dématérialisée
    • Ingénieurs des données
    • Autres
    • Ingénieurs AQ

      Ressources

    • Faits et mythes concernant la coopération avec un partenaire externe de développement de logiciels
    • Des États-Unis à l'Europe : Pourquoi les startups américaines décident-elles de se délocaliser en Europe ?
    • Comparaison des pôles de développement Tech Offshore : Tech Offshore Europe (Pologne), ASEAN (Philippines), Eurasie (Turquie)
    • Quels sont les principaux défis des CTO et des DSI ?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Conditions d'utilisation du site web

    Copyright © 2025 par The Codest. Tous droits réservés.

    fr_FRFrench
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek fr_FRFrench