Un composant Sass en 10 minutes

Dans ce bref article, Hugo Giraudel crée un composant Sass très simple et nous donne quelques bons principes de base pour construire nos propres composants. Limpide et passionnant comme toujours.

Par

Les développeurs sont d'accord pour reconnaître l'intérêt de construire un site ou une application à partir de composants, mais la mise en pratique de ce principe n'est pas toujours aussi aisée. Regardons cela en détail, en utilisant Sass.

Et puisque ne vaut un bon exemple, je propose de prendre un élément utilisé dans pratiquement tous les sites ou applications qui répondent à l'interaction utilisateur : des messages d'alerte (ou des notifications — ou le nom que leur donneront les cool kids d'aujourd'hui).

La création d'un composant nous permettant de générer différents types de messages d'alertes va nous permettre de booster notre niveau d'expertise en Sass. Allez, on retrousse nos manches et on y va !

Définir nos couleurs d'alertes

Que voulons-nous ? des messages ! Mais quelles sortes de messages ? Jetons un coup d'oeil sur un framework qui propose quelque chose de similaire : Bootstrap. Celui-ci définit 4 types de messages d'alerte :

  • Validation
  • Erreur
  • Avertissement
  • Information

Ça n'a pas l'air mal pour notre composant ! De la même façon que nous utilisons différents tons de voix pour exprimer différentes émotions, nous pouvons utiliser les couleurs pour transmettre un message sur le web. D'où 4 types d'alertes, chacune avec son propre code couleur. Là encore, empruntons à Bootstrap :

  • Vert pour succès
  • Rouge pour erreur
  • Jaune ou orange pour avertissement
  • Bleu clair pour information

Écrire nos styles de base

Tous les messages partageront des styles communs, comme le padding, les marges et probablement la typographie. Au final, la différenciation se fera par la couleur.

Comme je l'ai évoqué dans l'article Sass: Mixin ou Placeholder? une bonne pratique consiste à étendre un placeholder pour les règles statiques et à utiliser un mixin pour les règles dynamiques, c'est à dire celles qui peuvent changer en fonction de variables relatives au contexte.

Commençons avec le placeholder :

%message {
  padding: .5em;
  margin-bottom: .5em;
  border-radius: .15em;
  border: 1px solid;
}

Première chose à noter : nous ne spécifions pas de font styles comme size, family ou line height. Ce module sera utilisé dans un projet qui les a déjà définis quelque part, et c'est aussi une façon de mieux isoler notre composant.

Deuxième chose : nous ne définissons pas de couleur pour la bordure. La propriété border-color est par défaut currentcolor, qui est la valeur color généralement définie par le navigateur comme étant le noir.

Et maintenant le mixin :

@mixin message($color) {
  @extend %message;
  color: $color;
  border-color: lighten($color, 20%);
  background: lighten($color, 40%);
}

Comme vous le voyez, le mixin fait deux choses : tout d'abord il définit les propriétés liées aux couleurs, en prenant une couleur unique comme paramètre, et il crée deux variantes de la couleur grâce à la fonction lighten de Sass. Les fonctions de manipulation de couleurs de Sass sont très utiles pour réduire le nombre d'arguments dans un mixin.

Ensuite, notre mixin étend le placeholder %message de façon à ce que vous n'ayez pas à réécrire ces styles pour chaque type de message. Et ainsi, notre code est très DRY (Don't Repeat Yourself).

Appeler le mixin

Nous avons presque fini. Tout ce qu'il nous reste à faire c'est d'appeler le mixin pour chaque type de message, en passant la bonne couleur pour chacun :

.message-error {
  @include message(#b94a48);
}

.message-valid {
  @include message(#468847);
}

.message-warning {
  @include message(#c09853);
}

.message-info {
  @include message(#3a87ad);
}

Encore plus DRY

Ce que nous avons réalisé jusqu'ici est assez sympa. L'ajout d'une nouvelle alerte se fait tout simplement en copiant le mixin avec la couleur de notre choix dans une classe que nous aurons créée. Quid maintenant si nous voulions le rendre encore plus portable ?

Ce serait sympa de pouvoir mettre en correspondance chaque type d'alerte et chaque couleur. Nous avons un moyen pour ça : les listes imbriquées (nested lists). Nous pouvons y arriver très facilement en créant une liste bi-dimensionnelle et en utilisant une boucle sur la liste avec @each :

$message-types: (
  (error    #b94a48)
  (valid    #468847)
  (warning  #c09853)
  (info     #3a87ad)
) !default;

@each $message-type in $message-types {
  $type:  nth($message-type, 1);
  $color: nth($message-type, 2);

  .message-#{$type} {
    @include message($color);
  }
}

Ce code Sass produit exactement le même résultat que le précédent, sauf que maintenant les variables sont définies dans une liste. Vous pouvez mettre cette liste en haut de votre feuille de style ou de votre fichier de configuration, ce qui facilite le travail d'édition (ajout, modification, suppression).

Note : si vous prévoyez d'ajouter ce composant à une bibliothèque ou à un framework, le flag !default que j'ai inclu dans la variable @message-types vous permettra d'écraser la variable si nécessaire.

Utiliser map (Sass 3.3)

Nous pourrions utiliser le tout nouveau type Sass ajouté dans Sass 3.3, les maps. Les maps sont l'équivalent des associative arrays en PHP ou des objets en JavaScript. Elles mettent en correspondance une valeur et une autre.

$message-types: (
  error   :  #b94a48,
  valid   :  #468847,
  warning :  #c09853,
  info    :  #3a87ad
) !default;

@each $type, $color in $message-types {
  .message-#{$type} {
    @include message($color);
  }
}

Génial, non ?

Gestion élégante des erreurs

Les développeurs Sass laissent souvent de côté la gestion élégante des erreurs. Vous devriez toujours vous assurer que les paramètres passés dans vos fonctions et mixins sont exacts — et qu'ils provoquent un message d'alerte dans le cas contraire. Cela vaut beaucoup mieux que de laisser le compilateur se planter.

Dans notre cas, nous voulons être sûrs que l'argument $color passé dans le mixin est bien une couleur.

@mixin message($color) {
  @if type-of($color) == color {
    @extend %message;
    color: $color;
    border-color: lighten($color, 20%);
    background: lighten($color, 40%);
  }

  @else {
    @warn "#{$color} is not a color for `message`.";
  }
}

C'est suffisant pour éviter le plantage du compilateur s'il essaie d'éclaircir une valeur qui n'est pas une couleur valide, et ça indique au développeur la nature de l'erreur commise.

Pour conclure

En une trentaine de lignes de SCSS nous avons écrit un composant qui est propre et compréhensible, DRY et léger, portable et configurable, facile à passer à l'échelle. C'est un bon ensemble de règles à appliquer à tous vos composants. Ci-dessous une démo qui montre le code en action :

See the Pen Messages & @extend by Hugo Giraudel (@HugoGiraudel) on CodePen.


Intéressé par Sass ? Retrouvez une liste des meilleurs articles et ressources du web.

Tous les articles parus sur Sass dans La Cascade.


Ressources complémentaires en français :

L'approche DRY, don't repeat yourself, par Nicolas Hoffmann
Sass-Guidelines, une guide de style engagé, par Hugo Giraudel


original paru le dans Sitepoint. Eh oui, Hugo fait partie de ces français talentueux qui écrivent directement en anglais pour s'adresser au monde entier et n'ont pas le temps de traduire pour le public francophone.

Sur l'auteur : est un intégrateur web de Grenoble, passionné par HTML5 et CSS3 et spécialiste de Sass. Vous pouvez lire ses articles ou contributions dans Sitepoint, TheSassWay, Codrops, CSS-tricks, et DavidWalshBlog.
Il est l'auteur de BrowserHacks, Sassylists, et bien d'autres choses Sassy.
On peut le suivre sur Twitter ou visiter son site.

Traduit avec l'aimable permission de Sitepoint et de l'auteur.
Copyright Sitepoint © 2014.