Comme de plus en plus de développeurs utilisent SASS, nous devons faire attention au nombre de codes SASS. Nous pouvons partir de la syntaxe CSS (feuilles de style en cascade) pour expliquer certaines des particularités de la syntaxe SASS. Après tout, les guides de style CSS sont très courants.
Cet article présente principalement certaines fonctionnalités qui m'intéressent personnellement. Vous pourrez peut-être en bénéficier et créer votre propre ensemble de guides d'utilisation SASS.
Continuez à maintenir vos règles de formatage CSS et vos guides de style habituels
Cet article se concentre sur la discussion de certains contenus concernant SASS, mais sur cette base, les développeurs doivent conserver leurs bonnes règles de formatage existantes. Si vous n’avez pas encore développé votre propre ensemble de règles de formatage, voici une revue de quelques guides de style qui devraient vous aider à développer vos propres habitudes d’écriture CSS. Voici quelques-uns des éléments inclus :
1. Gardez l'indentation de ligne cohérente
2. Gardez le nombre d'espaces avant et après les deux points/accolades cohérent
3. Gardez un sélecteur par ligne et une règle par ligne
4. Essayez de écrivez les attributs pertinents dans Together
5. Ayez un plan pour les règles de dénomination des noms de classe
6. Évitez d'utiliser des sélecteurs d'identifiant CSS
7. Attendez
Apprenons ensuite à écrire du beau code SASS, en prenant comme exemple l'écriture d'une propriété de la classe .weather :
Première liste @extend(s)
Faire cela peut permettre aux développeurs de garder une idée claire, de pouvoir connaître immédiatement la relation entre cette classe et ses attributs et d'autres classes et leurs attributs, et de maintenir une idée claire de la cohérence des attributs et de la réutilisation des attributs.
Style normal
Imbrication des sélecteurs
Dans la section imbriquée, continuez à utiliser les règles de style ci-dessus. Les parties imbriquées doivent toujours venir en dernier.
Tous les préfixes des fournisseurs utilisent @mixins
Le préfixe du fournisseur (préfixe CSS) est très sensible au facteur temps. En raison des mises à jour des navigateurs modernes, ces préfixes seront de moins en moins utilisés. Vous pouvez vous adapter à ces changements en mettant à jour le contenu de vos mixins (ou certaines bibliothèques utilisées dans vos mixins seront mises à jour automatiquement). Même si le mixin ne comporte qu’une seule ligne, cela n’a pas d’importance.
Mais lorsque la privatisation de certains préfixes de fournisseurs est très sérieuse, ces préfixes seront très difficiles à standardiser et appliquer d'autres préfixes ou versions non préfixées n'en vaudra pas le gain, je choisirai d'abandonner @mixin ces préfixes de fournisseurs. Par exemple -webkit-line-clamp, -mscontent-zoom-chaining ou des situations similaires.
Ne pas imbriquer plus de 3 niveaux
Si vous imbriquez plus de trois fois, vous risquez d'écrire un sélecteur de triche (mauvais ?). La raison de la triche est que ce sélecteur s'appuie trop sur la structure du HTML (instable), qu'il est trop détaillé (la fonction est trop puissante et n'a aucune flexibilité), ou que la réutilisabilité est trop mauvaise (pas très utilisable). Dans le même temps, un trop grand nombre de niveaux d’imbrication peut facilement conduire à un code obscur et difficile à comprendre.
Parfois, il y a trop de code lié à une classe, il faut donc utiliser un sélecteur de balises. Vous devrez peut-être être très précis sur une classe pour éviter une cascade inutile. Même si cela est possible, utilisez extend pour profiter de certaines fonctionnalités de réutilisabilité de CSS.
Le code imbriqué ne doit pas dépasser 50 lignes
Si l'imbrication dans SASS fait plus de 50 lignes, elle risque de ne pas être entièrement affichée sur une page du compilateur, ce qui rendra le code difficile à lire et à comprendre. L'imbrication est initialement destinée à faciliter et simplifier la réflexion et l'organisation du code. Si cela viole la lisibilité, veuillez ne pas imbriquer.
Les séquences de fichiers SASS globales et régionales sont équivalentes au contenu des tables
En d’autres termes, ils n’ont pas de style fixe. Les développeurs doivent se rappeler de garder le style de toutes les parties cohérent et ordonné.
Répertoriez d'abord les bibliothèques fournisseur/globales, puis listez les bibliothèques personnalisées, puis les modes et enfin les bibliothèques utilisées par chaque division.
De cette façon, le « répertoire » ressemble à l’exemple suivant, qui est clair en un coup d’œil :
Ces fichiers sont comme une boussole, les couleurs et les mixins ne produisent pas de code CSS compilé, ce sont des bibliothèques purement autonomes. Des modèles ont ensuite été introduits pour rendre la réécriture plus sûre sans conflits de spécificité.
Divisez raisonnablement SASS en plusieurs petits fichiers
Il n'y a rien de mal à faire cela. Lorsque les circonstances le permettent, essayez d'utiliser plusieurs fichiers petits et précis, afin que les développeurs puissent trouver des fichiers spécifiques au lieu de chercher des aiguilles dans une botte de foin dans plusieurs gros fichiers avec un code long.
...
Ce que je fais souvent, c'est référencer ces fichiers un par un dans un fichier scss global, au lieu de référencer un fichier _header.scss, puis y faire référence un par un dans le fichier _header.scss. Cela peut réduire le temps d’indexation et améliorer l’efficacité de la lecture.
Vous pouvez utiliser le globbing lorsqu'il y a trop de fichiers et que la séquence d'importation est trop longue.
N'oubliez pas de nommer les Partiels _partial.scss
Il s'agit d'un nom courant pour les fichiers qui ne peuvent pas être compilés par eux-mêmes. Un tel fichier dépendra dans une certaine mesure d’autres fichiers, ce qui rendra impossible la compilation indépendante. Personnellement, j'aime ajouter un trait de soulignement avant le nom du fichier, tel que _dropdown-menu.scss
Ajouter un mappage de lignes
Voir ici, cela signifie que l'outil de développement peut vous indiquer la source de chaque règle, même s'il s'agit d'un fichier partiel importé.
Lors du déploiement, pensez à compiler les fichiers rationalisés
Une page Web en cours d'exécution doit toujours utiliser un minimum de CSS.
Pas besoin de soumettre un fichier .css
Cela peut prendre un certain temps, mais cela peut être très sympa de ne pas avoir de fichiers .css dans le référentiel. La compilation des fichiers se fait au moment du déploiement. Ainsi, la seule chose que vous pouvez voir, ce sont ces fichiers Sass magnifiquement formatés qui ont été rationalisés. Cela rend la description des fichiers très utile. La description du fichier permet de comparer certaines modifications apportées par l'éditeur de la version. Pour les fichiers .css déjà rationalisés, les descriptions de fichiers sont fondamentalement inutiles.
Notes d'utilisation généreuses
Les gens regrettent rarement d'avoir laissé des commentaires dans leur code. Qu'il s'agisse de commentaires utiles ou discrets, ils seront éventuellement effacés une fois compilés dans un fichier CSS simplifié, sans frais supplémentaires pour le développeur.
.overlay {
/* les modaux sont 6000, les messages enregistrés sont 5500, l'en-tête est 2000 */
z-index : 5000 ;
En parlant d'annotations, vous devrez peut-être également y apporter quelques ajustements de standardisation. Dans SASS, '//' est idéal pour ajouter des commentaires, et '//' rend les commentaires et décommentations très pratiques.
Convertir certaines valeurs couramment utilisées et valeurs ayant des significations particulières en variables
Si vous vous retrouvez à réutiliser une valeur (ce qui est très courant dans la conception front-end), vous feriez mieux de la convertir en variable. De cette façon, vous pouvez vous rappeler la signification de la valeur en la nommant et maintenir la cohérence lors de l'écriture du code. Oui, vous n'avez pas besoin d'ajuster ligne par ligne lorsque vous modifiez cette valeur.
Si un nombre a une signification évidente, alors le convertir en variable est essentiel.
et de convertir les couleurs en variables
Sauf noir et blanc. De nombreuses couleurs ne sont pas destinées à être utilisées une seule fois, même si vous pensez ne plus les utiliser. Mais si vous la convertissez en variable, vous pourriez la trouver utilisée ailleurs. Pour les variables de couleur, Sass dispose de fonctions de couleur qui peuvent les gérer, telles que lighten() et darkern(). Cela vous permet de contrôler facilement les couleurs globales (changez une fois, oubliez-le)
Imbibez et nommez vos bibliothèques multimédias
La fonction d'imbrication des médiathèques dans Sass signifie que 1. vous n'avez pas besoin de réécrire les sélecteurs à d'autres endroits et de provoquer des erreurs inutiles ; 2. les règles que vous réécrivez deviennent claires et claires, et quand celles-ci peuvent devenir très déroutantes ; lorsque le code est à la fin de votre code CSS ou dans d'autres fichiers.
Dans votre feuille de style globale, introduisez un fichier _shame.scss à la fin.
Vous êtes le leader qui décide de tout
Sass ne fera rien que vous ne lui dites pas de faire, donc la sortie finale du fichier sass est différente pour chacun. Écrire des fichiers CSS avec Sass, c'est comme ne pas utiliser Sass, vous êtes le leader du code.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
