Sass Best Practices Conseils et outils pour les développeurs

Un peu comme la façon dont jQuery a révolutionné le JavaScript vanille, Sass a révolutionné le CSS vanillé. La plupart des développeurs qui apprennent Sass conviennent qu'ils ne voudront jamais revenir en arrière. Beaucoup conviennent également que le plus gros problème des nouveaux développeurs est la façon ils utilisent Sass, pas Sass lui-même.

J'ai parcouru le Web et compilé cet article de Meilleures pratiques pour l'écriture de code Sass extensible et réutilisable. Les suggestions proviennent de mes propres opinions et de sites Web de confiance comme Sass Guidelines.

Vous n'avez certainement pas besoin de mettre en œuvre toutes ces fonctionnalités dans votre flux de travail. Mais cela vaut au moins de divertir ces idées et d’envisager les avantages potentiels..

Organisation du fichier

Le meilleur endroit pour commencer avec le développement Sass est l’organisation des fichiers. Si vous êtes déjà dans le code modulaire, vous devez comprendre la valeur des importations et des partiels (plus sur ces derniers plus tard).

Mais pour l'instant, jetez un coup d'œil à cet exemple de structure de fichiers de DoCSSa. J'ai recréé cette structure de fichier que vous pouvez voir ci-dessous:

Ceci n’est qu’une suggestion et c’est l’une des nombreuses façons d’organiser vos fichiers. Vous pouvez trouver d'autres méthodes qui utilisent différentes structures de dossiers comme “globals” pour SCSS à l'échelle du site et “des pages” pour SCSS spécifique à la page.

Passons en revue ce style d'organisation suggéré pour examiner l'objectif de chaque dossier:

• / globals - contient des fichiers Sass appliqués à l'ensemble du site, tels que la typographie, les couleurs et les grilles
• /Composants - contient des fichiers Sass avec des styles de composants tels que des boutons, des tableaux ou des champs de saisie
• /sections - contient des fichiers Sass dédiés à des pages ou à des zones spécifiques d'une page (il est préférable de les combiner dans le dossier / components /.)
• / utils - contient des utilitaires tiers tels que Normalize pouvant être mis à jour de manière dynamique avec des outils tels que Bower.
• main.scss - le fichier Sass principal dans le dossier racine qui importe tous les autres.

Ceci est juste un point de départ de base et il y a beaucoup de place pour développer vos propres idées.

Mais peu importe la façon dont vous choisissez d'organiser votre SCSS, il est crucial que vous avoir une organisation avec un fichier (ou dossier) séparé pour les bibliothèques telles que Normaliser qui doivent être mises à jour, plus des composants en partiels Sass pour votre projet.

Les partiels sass sont essentiels aux meilleures pratiques modernes. Celles-ci sont vivement recommandées par l'équipe de conception de Zurb et par de nombreux autres développeurs frontaux professionnels..

Voici une citation du site Sass expliquant les partiels:

“Vous pouvez créer des fichiers Sass partiels contenant de petits extraits de CSS que vous pouvez inclure dans d'autres fichiers Sass. C'est un excellent moyen de modularisez votre CSS et aidez à garder les choses plus faciles à maintenir. Un partiel est simplement un fichier Sass nommé avec un trait de soulignement. Vous pourriez l'appeler quelque chose comme _partial.scss. Le trait de soulignement indique à Sass que le fichier est un fichier partiel et qu'il ne doit pas être généré dans un fichier CSS. Les partiels Sass sont utilisés avec @importation directif.”

Jetez également un œil à ces autres articles sur la structure de fichier Sass:

• Comment je structure mes projets Sass
• Sass Esthétique: Organisation Architecture et Style
• Structures de répertoires qui vous aident à maintenir votre code

Stratégies d'importation

On ne peut pas en dire assez sur la valeur de l'importation Sass et des partiels. L'organisation du code est essentielle pour obtenir une structure d'importation et un flux de travail qui fonctionne.

Le meilleur endroit pour commencer est une feuille de globaux contenant les importations, les variables et les mixines. De nombreux développeurs préfèrent séparer les variables et les mixins, mais cela revient à la sémantique.

Gardez à l’esprit que les mixins sont un moyen d'importer ou plutôt de dupliquer le code Sass. Ils sont incroyablement puissants mais ne doivent pas être utilisés avec “statique” code. Gardez à l'esprit qu'il existe une différence entre mixins, extensions et espaces réservés, qui ont tous leur utilité dans le développement Sass..

Il est préférable d’utiliser les mixins avec des valeurs dynamiques transmises à mixin pour les modifications de code. Par exemple, consultez ce mixin Sass qui crée un dégradé de fond entre deux couleurs.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Anciens navigateurs * / arrière-plan: -moz-linear-gradient (en haut, $ top 0%, $ en bas 100%); / * FF3.6 + * / background: -webkit-gradient (linéaire, gauche en haut, gauche en bas, couleur-stop (0%, $ top), couleur-stop (100%, $ bas)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (en haut, 0% en haut, 100% en bas); / * Chrome10 +, Safari5.1 + * / arrière-plan: -o-linear-gradient (en haut, $ 0% en haut, $ en bas 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (en haut, 0% en haut, 0% en bas); / * IE10 + * / background: linéaire-dégradé (jusqu'en bas, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Le mixin prend deux valeurs: une couleur supérieure et une couleur inférieure. Vous pouvez écrire différents mixins pour différents types de dégradés comprenant 3 ou 4 couleurs différentes. Cela vous permet d'importer et de cloner le code mixin tout en modifiant les paramètres pour les options personnalisées..

L'exemple de Code responsable ressemble à ceci:

.bouton @include linearGradient (#cccccc, # 666666); 

Le paramètre fictif de Sass est lié au mixin, ce qui est principalement utile avec la directive extend. C'est certes plus complexe que mixins, mais cela peut être un moyen de combiner les sélecteurs ensemble sans réécrire le code en excès.

Bien que Sass n’ait qu’une seule méthode @import, j’ai inclus mixins et espaces réservés pour démontrer la flexibilité du code pouvant être écrit dans un fichier mais inclus n'importe où..

Lors de la construction d'une structure d'importation, rappelez-vous de suivre les concepts du codage DRY (ne vous répétez pas)..

Conventions de nommage

Les règles générales relatives aux conventions de dénomination s’appliquent aux variables, aux fonctions et aux mixins. Lorsque vous nommez quelque chose dans Sass, il est recommandé de utilisez toutes les lettres minuscules avec des tirets pour séparer.

La syntaxe de code Sass est en réalité basée sur les règles CSS. Voici quelques pratiques recommandées à garder à l'esprit:

• deux (2) espaces, sans tabulations
• idéalement, lignes larges de 80 caractères ou moins
• utilisation significative des espaces
• utiliser les commentaires pour expliquer les opérations CSS

Ces éléments ne sont pas obligatoires pour un code Sass valide. Mais ces suggestions viennent de développeurs professionnels qui ont trouvé ces règles fournissent l'expérience de codage la plus uniforme.

Mais en ce qui concerne les conventions de dénomination, vous pouvez vous retrouver avec deux structures différentes: une pour les noms Sass et une autre pour les noms de classes CSS. Certains développeurs préfèrent BEM aux suggestions Sass. Ni l'un ni l'autre n'est plus ou moins correct. juste différent avec différentes procédures d'exploitation.

Le problème est que BEM ne se transmet pas bien aux variables Sass ou aux mixins car elles ne possèdent pas la structure de bloc / élément / modificateur (BEM). Personnellement, je préfère utiliser les conventions de nommage Sass, mais vous pouvez essayer n'importe quoi, de camelCase à votre propre syntaxe interne..

Lors de l’organisation de vos variables et mixins, il est recommandé de: divisez-les par catégorie, puis listez-les par ordre alphabétique. Cela rend l'édition beaucoup plus facile car vous savez exactement où trouver quelque chose.

Par exemple, pour changer une couleur de lien, ouvrez votre fichier de variables (peut-être _variables.scss) et localisez la section pour les variables de couleur. Recherchez ensuite le lien par son nom (lien d’en-tête, lien de texte, etc.) et mettez à jour la couleur. Simple!

Pour avoir une idée de la structure d'une table des matières pour vos fichiers Sass, consultez le fichier de paramètres de la Fondation..

 // Paramètres Foundation for Sites // ----------------------------- // // Table des matières: // // 1 Global // 2. Points de coupure // 3. La grille // 4. Typographie de base // 5. Aide de typographie… // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // etc

Une autre pratique de nommage concerne points d'arrêt réactifs. Lorsque vous nommez des points d'arrêt Sass, essayez d'éviter les noms spécifiques à l'appareil. Il est préférable d'écrire des noms tels que petit, med, lg et xlg car ils sont par rapport à l'autre.

Cela est préférable pour les relations internes entre les points d'arrêt, mais également pour les équipes dans lesquelles les développeurs peuvent ne pas savoir quels périphériques sont liés les uns aux autres..

Pour ce qui est de noter les noms, il est recommandé de soyez aussi précis que possible sans variables très longues. Vous devriez adopter des conventions de nommage faciles à retenir pour l'ensemble du site en codant.

Donnez des conventions de dénomination spécifiques pour tout, comme les couleurs, les marges, les piles de polices et les hauteurs de ligne. Non seulement les noms peuvent être rapidement rappelés, mais facilite votre travail lorsque vous écrivez de nouveaux noms de variables devant correspondre à une syntaxe existante.

Mais il y a un fine ligne entre spécificité et convolution. La pratique vous aidera à trouver cette ligne, et écrire plus de noms mémorisables facilite la copie de code dans d'autres projets..

Nesting and Looping

Ces deux techniques de Sass sont très différentes en action, mais elles ont toutes les deux capacité à être maltraité s'il n'est pas utilisé avec précaution.

Nidification est le processus de ajout de sélecteurs imbriqués par indentation pour créer plus de spécificité avec moins de code. Sass propose un guide d'imbrication illustrant des exemples d'imbrication de code en action. Mais il est facile de se laisser emporter par la nidification. Si vous êtes trop zélé, vous pouvez vous retrouver avec un code qui ressemble à ceci:

body div.content div.container … body div.content div.container div.articles … body div.content div.container div.articles> div.post … 

Beaucoup trop spécifique et presque impossible à écraser, ce type de code va à l'encontre du but des feuilles de style en cascade.

En parcourant ce guide SitePoint, vous trouverez trois règles d'or pour l'imbrication:

• Ne jamais aller plus de 3 niveaux de profondeur.
• S'assurer que la sortie CSS est propre et réutilisable.
• Utilisez l'imbrication lorsque cela vous semble judicieux, pas comme une option par défaut.

Le développeur Josh Broton suggère d'imbriquer si nécessaire, indenter le reste comme règle de syntaxe générale.

Indenter vos sélecteurs ne causera aucun effet CSS en cascade. Mais vous aurez plus de facilité à parcourir votre fichier Sass en repérant les classes les unes par rapport aux autres.

Les boucles peuvent aussi être surutilisé s'il n'est pas appliqué correctement. Les trois boucles de Sass sont @pour, @tandis que, et @chaque. Je n'entrerai pas dans les détails sur leur fonctionnement, mais si cela vous intéresse, consultez ce post..

J'aimerais plutôt couvrir le but d'utiliser des boucles et comment ils fonctionnent dans Sass. Ceux-ci devraient être utilisés pour gagner du temps à l'écriture de code pouvant être automatisé. Par exemple, voici un extrait de code du message de Clubmate montrant du code Sass suivi de la sortie:

/ * Code Sass * / @for $ i de 1 à 8 $ width: pourcentage (1 / $ i) .col - # $ i width: $ width;  / * sortie * / .col-1 largeur: 100%; .col-2 largeur: 50%; .col-3 largeur: 33,333%; .col-4 largeur: 25%;  .col-5 largeur: 20%; .col-6 largeur: 16,666%; .col-7 largeur: 14,285%; .col-8 largeur: 12,5%;

Ces classes de colonnes peuvent être utilisées avec un système de grille. Vous pouvez même ajouter plus de colonnes ou en supprimer quelques-unes simplement en modifiant le code de la boucle.

Boucles devrait ne pas être utilisé pour dupliquer des sélecteurs ou des propriétés pour un sélecteur; c'est à quoi servent les mixins.

Aussi, lors de la mise en boucle, il existe quelque chose appelé Sass maps qui stocke des paires de données clé: valeur. Les utilisateurs avancés devraient en tirer parti dès que possible.

Mais les boucles Sass classiques sont simples et efficaces pour fournir une sortie de code sans répétition. La meilleure raison d'utiliser des boucles est avec Propriétés CSS qui varient en sortie de données.

Voici un bon moyen de vérifier si votre boucle est utile: demandez-vous s'il existe un autre moyen de générer le CSS dont vous avez besoin avec moins de lignes de code. Sinon, la syntaxe de la boucle est probablement une excellente idée..

Si vous êtes un peu déconcerté ou si vous souhaitez des commentaires sur les boucles d'imbrication ou Sass, vous devez poser une question dans / r / sass / ou / r / css /, communautés actives de Reddit avec des développeurs Sass très compétents..

La modularisation

La pratique de l'écriture modulaire en sass est une nécessité absolue pour la plupart des projets (dirais-je, tous les projets). La modularisation est le processus de décomposer un projet en modules plus petits. Ceci peut être accompli dans Sass en utilisant partiels.

L'idée de base de Sass modulaire est d'écrire des fichiers SCSS individuels dans un but spécifique, ciblant un contenu global (typographie, grilles) ou des éléments de page (onglets, formulaires)..

La définition du module Sass est assez claire et fait une suggestion très spécifique: l'importation d'un module ne doit jamais générer de code.

L'idée d'une sortie obligatoire pour tous les modules serait un cauchemar d'optimisation. Au lieu de cela, vous devez créer des modules individuellement et appelez seulement ceux dont vous avez besoin. Les modules peuvent être définis par des mixins ou des fonctions, mais il est possible de créer des modules contenant également des sélecteurs.

Cependant, un article de Sass Way suggère d’écrire tous les sélecteurs en tant que mixins et de ne les appeler que si besoin est. Que vous adoptiez ceci ou non, c’est finalement votre choix. Je pense que cela dépend de la taille du projet et de votre confort avec la manipulation de mixins.

Citant John Long de son post sur The Sass Way:

“Pour moi, les modules sont devenus les unités de base ou les blocs de construction de mes projets Sass.”

Si vous êtes vraiment à la recherche d'une routine Sass, je vous recommande d'aller de l'avant de manière totalement modulaire Essayez de construire presque tout comme un partiel modulaire à inclure dans un fichier CSS principal. Au début, ce flux de travail peut sembler décourageant, mais cela a du sens à plus grande échelle, en particulier pour les grands projets..

De plus, il est beaucoup plus facile de copier des modules d'un projet à un autre lorsqu'ils sont situés dans des fichiers séparés.. La flexibilité et code réutilisable sont les pierres angulaires du développement modulaire.

Pour en savoir plus sur les modules Sass et les techniques de modularisation, consultez ces articles:

• Modules CSS: Bienvenue dans le futur
• Les avantages et inconvénients de Sass modulaire
• Organisation CSS modulaire avec SMACSS & SASS

Trouvez votre flux de travail parfait

Chaque équipe et chaque développeur a ses propres pratiques qui fonctionnent le mieux. Vous devez adopter les pratiques qui fonctionnent le mieux pour vous personnellement ou choisir celles qui fonctionnent le mieux pour votre équipe de manière professionnelle..

Pensez également à utiliser Gulp ou Grunt pour automatiser vos projets et minimiser votre code. Cela économisera beaucoup de travail manuel et les outils d'automatisation font désormais partie des meilleures pratiques pour le développement frontal moderne.

Parcourez les bibliothèques open source telles que SCSS de la Fondation sur GitHub pour en savoir plus sur les meilleures pratiques utilisées par d'autres bibliothèques..

Le problème des meilleures pratiques est qu’elles améliorent vraiment votre travail la plupart du temps, mais il existe de nombreuses alternatives. Juste essayer des choses et voir comment ils se sentent. Vous apprendrez toujours pour que vos meilleures pratiques changent rapidement en 5 ans.

Une dernière suggestion que j'ai pour l'ensemble du processus Sass est de prendre des décisions avec clarté d'esprit. Écrivez un code qui facilite votre travail. Ne pas trop compliquer un projet s'il existe un moyen plus simple de le faire.

Sass est destiné à améliorer l'expérience de développement CSS, donc travailler avec clarté et meilleures pratiques pour obtenir la meilleure expérience possible.

Emballer

La congestion dans un flux de travail Sass peut être corrigée en modifiant les styles de code et en appliquant les meilleures pratiques. J'ai présenté quelques suggestions dans ce billet provenant de blogs Sass et de développeurs professionnels..

Le meilleur moyen d’en savoir plus est d’appliquer ces pratiques dans votre flux de travail et voir ce qui fonctionne. Au fil du temps, vous constaterez que certaines activités sont plus bénéfiques que d’autres, auquel cas vous devriez garder ce qui fonctionne et laisser tomber ce qui ne.

Consultez ces liens pour trouver d'autres astuces et meilleures pratiques pour le développement de Sass:

• Directives Sass
• Une vision pour notre sass
• 8 conseils pour vous aider à tirer le meilleur parti de Sass
• Étendre Sass sans créer de désordre
• Meilleures pratiques Sass - Imbrication de plus de 3 niveaux