Fleche retour aux articles de blogQuelle structure pour votre Sass ?

Travailler avec du CSS est devenu à la fois plus intéressant et plus complexe suite à l’introduction de nouveaux outils comme les préprocesseurs, ou de nouveaux besoins, comme l’intégration responsive des pages web.

Cette complexité grandissante nécessite une organisation plus réfléchie et plus maintenable. Fini le temps des fichiers CSS uniques de plusieurs milliers de lignes, cependant il n’est pas forcément évident de définir une organisation stable et le but de cet article est de vous permettre d’y voir un peu plus clair.

Mots clés :

web

front-end

Mettre en forme votre architecture

Un de bénéfices principaux des préprocesseurs CSS tel que Sass et la possibilité de séparer votre code en plusieurs fichiers différents, sans impacter la performance. Grâce à la directive @import de Sass, vous pouvez mettre en place autant de fichiers que vous le voulez au niveau de votre développement : ils seront ensuite compilés en un fichier unique pour la production !

Une bonne organisation débute par une bonne découpe de votre CSS en plusieurs dossiers et fichiers. Une place pour chaque chose et chaque chose à sa place !

N’ayez pas peur des dossiers

Les dossiers sont essentiels. Chez vous, vous ne déposez pas tous vos documents dans le même tiroir ? Vous avez probablement des dossiers, séparés par responsabilités ou champ d’intérêt : un pour vos documents personnels, un pour vos documents administratifs, un pour vos documents bancaires, etc.

Et bien c’est exactement la même chose que nous allons faire pour organiser nos fichiers Sass : nous n’allons pas simplement tout mettre au même endroit, nous allons les catégoriser.

Spoiler alert, voici l’architecture de fichiers que nous allons mettre en place :

sass/ 
| 
|– base/ 
|   |– _reset.scss       # Reset/normalize 
|   |– _typography.scss  # Typography rules 
|   ...                  # Etc… 
| 
|– utils/ 
|   |– _variables.scss   # Sass Variables 
|   |– _functions.scss   # Sass Functions 
|   |– _mixins.scss      # Sass Mixins 
|   |– _helpers.scss     # Class & placeholders helpers 
|   ...                  # Etc… 
|
|– layout/ 
|   |– _grid.scss        # Grid system 
|   |– _header.scss      # Header 
|   |– _footer.scss      # Footer 
|   |– _sidebar.scss     # Sidebar 
|   |– _forms.scss       # Forms 
|   ...                  # Etc… 
| 
|– components/ 
|   |– _buttons.scss     # Buttons 
|   |– _carousel.scss    # Carousel 
|   |– _cover.scss       # Cover 
|   |– _dropdown.scss    # Dropdown 
|   |– _navigation.scss  # Navigation 
|   ...                  # Etc… 
|
|– pages/ 
|   |– _home.scss        # Home specific styles 
|   |– _contact.scss     # Contact specific styles 
|   ...                  # Etc… 
| 
|– themes/ 
|   |– _theme.scss       # Default theme 
|   |– _admin.scss       # Admin theme 
|   ...                  # Etc… 
| 
|– vendors/ 
|   |– _bootstrap.scss   # Bootstrap 
|   |– _jquery-ui.scss   # jQuery UI 
|   ...                  # Etc… 
| 
| 
`– main.scss             # primary Sass file

Comme vous pouvez le constater, il n’y a qu’un seul fichier Sass à la racine de notre dossier principal : main.scss . Tous les autres fichiers sont séparés dans des dossiers appropriés et préfixés par un tiret bas, (_) pour indiquer à Sass que ce sont des fichiers .scss partiels qui ne doivent pas être compilés en fichiers CSS indépendants. En effet, c’est uniquement dans notre fichier scss racine que nous allons les importer et les compiler.

Base

Le dossier base contient ce que nous pourrions appeler les fichiers passe-partout de notre projet. À l’intérieur de ce dossier nous pouvons retrouver un fichier “reset” ou “normalize” qui va s’assurer d’écraser des comportements non-standards liés aux navigateurs par exemple, ou des fichiers qui se chargent de la typographie et de l’import des polices.

  • _reset.scss ou _normalize.scss
  • _typography.scss
  • _fonts.scss

Utils

Le dossier utils(parfois aussi appelé abstract ou helpers) regroupe tous les outils Sass que nous allons exploiter dans le projet. Les fonctions, les mixins, les variables… Tous ces éléments sont rangés dans ce dossier afin de pouvoir les réutiliser sans crainte par la suite.

Une règle de ce dossier est qu’il ne devrait pas résulter directement une seule ligne de CSS lors de la compilation. En effet les outils qui le composent sont utilisés dans les autres fichiers mais n’ont pas d’intérêt indépendant.

  • _variables.scss
  • _mixins.scss
  • _functions.scss
  • _placeholders.scss

Layout

Le dossier layout/ (parfois appelé partials/) contient en général un bon nombre de fichiers, ayant chacun la responsabilité de mettre en place le style des sections principales de la mise en page de notre site web : le header, le footer, etc. Il contient aussi le fichier _grid s’il est nécessaire, qui est utilisé pour construire le socle de cette mise en page.

  • _grid.scss
  • _header.scss
  • _footer.scss
  • _navigation.scss

Components

Pour les règles dédiées aux composants des pages du site, nous allons utiliser le dossier components/ (parfois aussi appelé modules/). Là ou le dossier layout/ à pour objectif de regrouper les éléments structurels, components/ regroupe les briques qui viennent se ranger dans la structure du site. C’est dans ce dossier que se retrouvent les modules spécifiques, comme un carrousel, une barre de chargement, une carte produit, etc. C’est souvent le dossier le plus remplis puisqu’une bonne pratique consiste à découper au maximum votre site en petits modules qui auront donc tous leur fichier Sass partiel dans ce dossier.

  • _carrousel.scss
  • _loader.scss
  • _banner.scss

Pages

Si vous avez des règles de style spécifiques à certaines pages, il peut être pertinent de les ranger dans un dossier pages/ dédié. Souvent, la page d’accueil possède des éléments spécifiques et un style customisé par rapport au reste du site, dans ce cas un fichier _home.scss pourra regrouper l’ensemble de ces règles. Une landing page, une page de contact ou une page de téléchargement sont d’autres exemples qui ont couramment un style suffisamment différent du reste du site pour justifier l’utilisation d’un fichier dédié.

  • _home.scss
  • _contact.scss

Un point d’attention : puisque ces styles sont pertinents uniquement sur les pages en question, il est parfois préférable de ne pas utiliser de fichiers partiels, afin de ne pas compiler ces styles dans le fichier CSS principal de votre site. Une bonne pratique serait au contraire de les compiler chacun dans un fichier dédié et d’uniquement les importer dans les pages nécessaires. Par exemple, le fichier home.scss pourra être compilé en home.css et n’être importé que dans votre page index.html.

Themes

Si vous travaillez sur des sites de grande envergure avec de nombreux thèmes différents, par exemple en fonction du rôle de l’utilisateur connecté dans le cas d’une interface back-office, la mise en place d’un dossier themes/ peut s’avérer utile. Vous pourrez y ranger les styles spécifiques à ces différents thèmes. Cependant ce dossier n’est pas obligatoire et sa nécessité est à estimer au cas par cas en fonction des projets.

  • _admin.scss
  • _editor.scss
  • _manager.scss

Vendors

Enfin, vous aurez probablement besoin d’un dossier vendors/ contenant tous les fichiers CSS et Sass en provenance de librairies ou de frameworks externes à votre projet. Bootstrap, JQuery, Vuetify… Tout ce qui vient de l’extérieur se range dans ce dossier ! Les placer au même endroit, bien séparé du reste permet de distinguer rapidement ce qui est de votre responsabilité de ce qui ne l’est pas.

  • bootstrap.scss
  • vuetify.scss
  • D3.scss

Si vous avez besoin de surcharger le comportement de certaines portions du code de ces fournisseurs externes, vous pouvez ajouter ces fichiers en les préfixant, ou même créer un nouveau dossier vendors-extensions/ afin de maintenir au maximum cette séparation de la responsabilité.

Pour conclure

Ces recommandations ne sont peut-être pas toutes adaptées à votre projet, à votre équipe ou à vos besoins. Cependant elles sont simples à mettre en place et garantissent le minimum de clarté nécessaire pour faciliter le développement et surtout la maintenance de vos règles Sass.

Si vous avez besoin d’apporter des modifications, mais que vous ne savez pas si elles sont justifiées ou “propre”, la règle d’honneur reste KISS (Keep It Simple, Stupid) ! Si c’est simple à mettre en place, simple à comprendre et simple à maintenir, alors il y a de grandes chances pour que ce soit une bonne méthode !

Et voilà ! C’est à peu près tout pour cette architecture qui se base sur le 7-1 Pattern définit dans les guidelines Sass que vous pourrez retrouver ici et qui a été défini par Kitty Giraudel et que je vous ai retranscrite ici ! Je vous invite à suivre son travail exhaustif sur le sujet si le Sass vous intéresse !