Écrire du SCSS "qui fonctionne" est une chose. Écrire du SCSS maintenable et produire un CSS performant en est une autre. Dans ce chapitre, on se concentre sur les réflexes professionnels : éviter les pièges courants (spécificité, nesting abusif, duplication), garder un code lisible, et livrer un CSS final raisonnable en taille et en complexité.
@extend sur le CSS final.Les performances ne se gagnent pas avec une astuce magique : elles se gagnent avec de la discipline (moins de CSS généré, moins de complexité, moins de surprises).
Il est tentant d'utiliser toutes les fonctionnalités (boucles, maps imbriquées, conditions partout). Mais un SCSS trop "intelligent" peut devenir illisible.
Si un collègue met plus de 30 secondes à comprendre une règle, elle est probablement trop complexe.
Les "gros problèmes" viennent souvent d'un CSS qui grossit sans contrôle, pas d'un détail micro-optimisé.
Un nesting léger est lisible. Un nesting profond est fragile.
Bon usage :
/* ✅ Bon : nesting peu profond, lié au composant */
.card {
padding: 16px;
.card__title {
font-weight: 800;
}
&:hover {
transform: translateY(-1px);
}
}Mauvais usage :
/* ❌ Mauvais : nesting trop profond, couplé au HTML */
.page {
.layout {
.content {
.article {
.title {
color: red;
}
}
}
}
}Plus ton nesting est profond, plus tu "cimentes" ton CSS à une structure HTML précise. Le jour où le HTML change, tout casse.
Si tu écris des sélecteurs trop spécifiques, tu finiras par faire des overrides encore plus spécifiques.
Exemple à éviter :
/* ❌ Trop spécifique */
header nav ul li a {
color: white;
}
/* ✅ Plus simple, plus maintenable */
.nav__link {
color: white;
}Les mixins sont utiles, mais si elles injectent beaucoup de règles, elles peuvent gonfler ton CSS.
/* Mixin "lourde" (beaucoup de styles) */
@mixin card-heavy {
padding: 16px;
border-radius: 12px;
background: rgba(255,255,255,.08);
box-shadow: 0 10px 30px rgba(0,0,0,.15);
transition: transform .2s ease, box-shadow .2s ease;
&:hover {
transform: translateY(-2px);
box-shadow: 0 12px 40px rgba(0,0,0,.2);
}
}
/* ⚠️ Inclure partout peut dupliquer énormément de CSS */
.card-a { @include card-heavy; }
.card-b { @include card-heavy; }
.card-c { @include card-heavy; }
Si tu as un "style de base" identique, utilise plutôt un placeholder + @extend
(ou un composant unique) pour mutualiser, et garde les mixins pour les variantes paramétrables.
Générer des utilitaires est pratique, mais il faut limiter le scope.
$space-unit: 8px;
$levels: 0, 1, 2, 3, 4, 5; // ✅ bornes raisonnables
@each $i in $levels {
.m-#{$i} { margin: $space-unit * $i; }
.p-#{$i} { padding: $space-unit * $i; }
}Si tu passes à 0..50, tu crées des dizaines (voire centaines) de classes inutiles.
Les tokens améliorent la cohérence et réduisent la duplication.
$tokens: (
radius: (
sm: 6px,
md: 12px,
lg: 20px
),
space: (
1: 8px,
2: 16px,
3: 24px
)
);
@function token($group, $key) {
@return map-get(map-get($tokens, $group), $key);
}
.card {
border-radius: token(radius, md);
padding: token(space, 2);
}Les tokens sont aussi une "documentation vivante" : ils montrent comment le design est censé fonctionner.
@extend sur des sélecteurs complexes
Comme vu au chapitre 13, @extend peut produire des sélecteurs énormes.
La bonne pratique est d'étendre des placeholders simples.
%btn-base {
padding: 10px 16px;
border-radius: 12px;
font-weight: 700;
}
.btn {
@extend %btn-base;
}
.btn--primary {
@extend %btn-base;
background: #7aa7ff;
color: white;
}Le SCSS est un outil. La vraie qualité se voit dans le CSS final : taille, lisibilité, cohérence.
Tu as l'impression d'être "bien organisé" parce que tout est imbriqué, mais tu crées des sélecteurs fragiles et difficiles à surcharger proprement.
Les mixins sont parfois utilisées comme un copier-coller élégant. Si tu inclues un gros bloc partout, tu gonfles ton CSS.
Un "mini Tailwind maison" mal contrôlé peut exploser la taille du CSS. Il faut des limites et une vraie raison.
Plus tu augmentes la spécificité, plus tu augmentes la dette CSS (overrides, exceptions).
@extend doivent être utilisés avec discipline.