Cas pratiques Sass / SCSS

Contexte : Plusieurs composants partagent les mêmes propriétés CSS (padding, border-radius, box-shadow). Le Problème : Les styles sont copiés-collés dans plusieurs classes. Contraintes : Utiliser @extend ou placeholder selectors (%). Code actuel : .card { padding: 20px; border-radius: 8px; } .panel { padding: 20px; border-radius: 8px; } Livrable attendu : Refactoriser le code en utilisant un placeholder SCSS pour éviter la duplication.

Contexte : Un fichier SCSS contient des niveaux d'imbrication trop profonds. Le Problème : La spécificité CSS devient excessive et difficile à maintenir. Contraintes : Réduire l'imbrication tout en conservant la structure logique. Code actuel : .nav { ul { li { a { color: blue; } } } } Livrable attendu : Refactoriser la structure pour limiter la profondeur d'imbrication et améliorer la maintenabilité.

Contexte : Une application contient plusieurs media queries répétées pour gérer le responsive. Le Problème : Les breakpoints sont dupliqués dans tout le projet, ce qui complique leur modification. Contraintes : Utiliser uniquement les mixins SCSS. Aucun framework externe. Livrable attendu : Créer un mixin SCSS pour centraliser les breakpoints et simplifier l'écriture des media queries.

Contexte : Plusieurs boutons partagent la même structure mais ont des couleurs différentes. Le Problème : Chaque bouton possède son propre bloc CSS répété. Contraintes : Utiliser un mixin SCSS paramétré. Livrable attendu : Implémenter un mixin permettant de générer facilement différents styles de boutons selon une couleur passée en paramètre.

Contexte : Un projet nécessite un système de colonnes simple pour structurer les pages. Le Problème : Les largeurs sont calculées manuellement. Contraintes : Utiliser un mixin SCSS paramétré. Livrable attendu : Implémenter un mixin permettant de générer des classes de colonnes dynamiques basées sur un nombre total de colonnes.

Contexte : Une application nécessite plusieurs classes utilitaires pour gérer les marges (margin-1, margin-2, margin-3...). Le Problème : Les classes sont écrites manuellement, ce qui alourdit le code. Contraintes : Utiliser une boucle @for en SCSS. Livrable attendu : Générer automatiquement plusieurs classes utilitaires de marge à l'aide d'une boucle SCSS.

Contexte : Une application possède plusieurs variantes de couleurs pour alertes (success, error, warning). Le Problème : Les couleurs sont codées en dur dans différentes classes. Contraintes : Utiliser une map SCSS et une boucle. Livrable attendu : Définir une map de couleurs et générer automatiquement les classes correspondantes.

Contexte : Une équipe souhaite calculer dynamiquement des largeurs en pourcentage à partir d'un nombre de colonnes. Le Problème : Les calculs sont écrits manuellement et ne sont pas dynamiques. Contraintes : Utiliser une fonction SCSS personnalisée. Livrable attendu : Créer une fonction SCSS qui retourne la largeur en pourcentage en fonction d'un nombre de colonnes donné.

Contexte : Un projet front-end contient un seul fichier SCSS volumineux difficile à maintenir. Le Problème : Les styles globaux, composants et variables sont mélangés dans le même fichier. Contraintes : Utiliser la modularisation SCSS avec partials et @use. Livrable attendu : Proposer une organisation modulaire claire séparant variables, mixins et composants.

Contexte : Vous reprenez une interface web dont les couleurs principales sont répétées dans plusieurs fichiers CSS. Le Problème : La couleur principale et la couleur secondaire sont écrites en dur à plusieurs endroits, rendant les modifications longues et risquées. Contraintes : Vous devez utiliser des variables SCSS uniquement. Aucun changement HTML autorisé. Code actuel : .button { background-color: #3498db; } .card-title { color: #3498db; } .alert { border-color: #3498db; } Livrable attendu : Refactoriser le code en utilisant des variables SCSS pour centraliser les couleurs et améliorer la maintenabilité.

Contexte : Plusieurs composants utilisent des styles similaires mais avec des variations facultatives (padding, radius, shadow). Le Problème : Les variantes sont dupliquées dans différentes classes. Contraintes : Créer un mixin SCSS avec paramètres optionnels et valeurs par défaut. Livrable attendu : Implémenter un mixin flexible permettant de générer des variantes cohérentes tout en réduisant la duplication de code.

Contexte : Une application doit supporter plusieurs thèmes (clair, sombre, corporate) avec des palettes différentes. Le Problème : Les couleurs sont codées en dur dans plusieurs composants, rendant le changement de thème complexe. Contraintes : Utiliser des maps SCSS et des boucles. Aucun JavaScript. Livrable attendu : Implémenter une structure SCSS utilisant des maps pour définir les thèmes et générer dynamiquement les classes correspondantes.

Contexte : Une application nécessite une échelle typographique cohérente pour titres et textes. Le Problème : Les tailles sont définies manuellement sans logique centralisée. Contraintes : Utiliser une fonction SCSS pour générer une échelle modulaire. Livrable attendu : Implémenter une fonction permettant de calculer dynamiquement les tailles de police à partir d'une base et d'un ratio.

Contexte : Le projet utilise plusieurs breakpoints répétés dans différents fichiers. Le Problème : Les valeurs sont dupliquées et difficiles à maintenir. Contraintes : Centraliser les breakpoints dans une map SCSS et créer un mixin dédié. Livrable attendu : Mettre en place une configuration centralisée des breakpoints permettant une gestion cohérente du responsive.

Contexte : Une application nécessite un ensemble cohérent de classes utilitaires pour gérer spacing et couleurs. Le Problème : Les classes sont écrites manuellement, ce qui augmente le risque d'erreur et la taille du fichier. Contraintes : Utiliser une map SCSS et une boucle @each. Livrable attendu : Générer dynamiquement des classes utilitaires à partir d'une configuration centralisée.

Contexte : Plusieurs composants partagent des styles de base similaires. Le Problème : Les styles communs sont copiés-collés dans différentes classes. Contraintes : Utiliser des placeholders (%) et @extend de manière contrôlée. Livrable attendu : Refactoriser le code en utilisant des placeholders partagés tout en évitant les effets indésirables de cascade.

Contexte : Une application utilise un système de colonnes personnalisé calculé manuellement. Le Problème : Les largeurs sont écrites en pourcentage fixe, ce qui complique les ajustements globaux. Contraintes : Utiliser une fonction SCSS pour calculer dynamiquement les largeurs en fonction du nombre total de colonnes. Livrable attendu : Implémenter une fonction SCSS calculant les largeurs de colonnes et un mixin pour générer les classes correspondantes.

Contexte : Vous reprenez un projet front-end où toutes les variables, mixins et composants sont définis dans un seul fichier SCSS volumineux. Le Problème : La maintenabilité est faible, les dépendances sont floues et les conflits deviennent fréquents lors des évolutions. Contraintes : Utiliser les partials et la directive @use moderne. Aucun framework CSS externe autorisé. Livrable attendu : Proposer une architecture SCSS modulaire claire séparant variables, mixins, fonctions et composants, avec un point d'entrée principal structuré.

Contexte : Le projet utilise encore @import dans plusieurs fichiers SCSS. Le Problème : Les imports globaux provoquent des collisions de variables et une mauvaise isolation des modules. Contraintes : Migrer vers @use et @forward selon les bonnes pratiques modernes. Livrable attendu : Refactoriser la structure SCSS afin d'adopter le système de modules moderne avec encapsulation correcte.

Contexte : Un projet SCSS contient des niveaux d'imbrication très profonds entraînant une forte spécificité CSS. Le Problème : Les styles deviennent difficiles à surcharger et à maintenir. Contraintes : Réduire l'imbrication et adopter une convention structurée comme BEM. Code actuel : .card { .header { .title { span { color: red; } } } } Livrable attendu : Refactoriser la structure en limitant la profondeur d'imbrication et en améliorant la maintenabilité globale.

Contexte : Vous devez structurer un design system destiné à être utilisé par plusieurs équipes sur un produit SaaS en croissance. Le Problème : Les couleurs, espacements, typographies et composants sont définis de manière dispersée, sans hiérarchie claire ni logique centralisée. Contraintes : Utiliser exclusivement SCSS moderne avec @use et @forward. Aucun framework externe. Séparer clairement tokens, abstractions et composants. Livrable attendu : Concevoir une architecture SCSS complète incluant design tokens (colors, spacing, typography), mixins utilitaires, fonctions et organisation modulaire robuste prête à évoluer.

Contexte : L'application doit permettre un changement de thème partiel côté runtime tout en conservant la puissance de SCSS au build. Le Problème : Les variables SCSS sont statiques et ne permettent pas de changement dynamique en production. Contraintes : Combiner variables SCSS et CSS Custom Properties de manière stratégique. Livrable attendu : Mettre en place un système hybride permettant génération statique via SCSS et personnalisation dynamique via variables CSS au runtime.

Contexte : Une librairie interne de composants doit supporter de multiples variantes (size, state, theme) combinables. Le Problème : Les variantes sont gérées via duplication de classes, ce qui augmente fortement la taille du CSS. Contraintes : Utiliser mixins paramétrés et maps pour générer dynamiquement les variantes. Livrable attendu : Concevoir une architecture SCSS capable de générer proprement les variantes de composants sans explosion combinatoire du code.

Contexte : Un projet nécessite un système de grille totalement configurable (nombre de colonnes, gutters, breakpoints). Le Problème : Les largeurs sont codées manuellement, ce qui limite la flexibilité et la cohérence. Contraintes : Utiliser fonctions SCSS, mixins paramétrés et maps centralisées pour les breakpoints. Livrable attendu : Concevoir un générateur de grille complet capable de produire dynamiquement les classes de colonnes selon une configuration centralisée.

Contexte : Une application souhaite générer dynamiquement des classes utilitaires pour spacing, couleurs et alignements. Le Problème : Les utilitaires sont codés manuellement, entraînant duplication et incohérences. Contraintes : Utiliser maps imbriquées, @each et fonctions personnalisées. Livrable attendu : Implémenter un générateur configurable capable de produire automatiquement des utilitaires cohérents à partir d'une configuration unique.

Contexte : Une application B2B doit supporter plusieurs marques (white-label) avec palettes et variations spécifiques. Le Problème : Les styles sont dupliqués par marque, rendant les mises à jour longues et risquées. Contraintes : Utiliser des maps SCSS imbriquées, fonctions personnalisées et génération automatique via boucles. Livrable attendu : Mettre en place un système de theming avancé basé sur maps imbriquées permettant de générer dynamiquement les variantes de marque sans duplication de code.

Contexte : Un produit doit adopter une typographie fluide adaptée à toutes tailles d'écran sans multiplier les media queries. Le Problème : Les tailles sont fixes et nécessitent des ajustements manuels pour chaque breakpoint. Contraintes : Utiliser fonctions SCSS combinées avec clamp() et variables CSS. Livrable attendu : Concevoir un système typographique fluide paramétrable générant automatiquement des tailles cohérentes selon une échelle modulaire.

Contexte : Un projet historique utilise massivement @import avec variables globales partagées. Le Problème : Les collisions de variables et dépendances implicites rendent les évolutions risquées. Contraintes : Migrer vers @use et @forward avec encapsulation stricte. Livrable attendu : Refactoriser entièrement la structure SCSS pour adopter le système de modules moderne en garantissant isolation et maintenabilité.

Contexte : Une application complexe souffre de conflits CSS liés à une spécificité excessive et des dépendances croisées entre composants. Le Problème : Les styles deviennent imprévisibles lors de l'ajout de nouveaux modules. Contraintes : Refactoriser via placeholders, organisation modulaire et réduction stratégique de l'imbrication. Livrable attendu : Proposer une stratégie complète d'isolation des styles réduisant la spécificité tout en maintenant la cohérence visuelle.

Contexte : Un projet multi-modules utilise des breakpoints dispersés et incohérents. Le Problème : Les media queries sont répétées et difficiles à maintenir. Contraintes : Centraliser breakpoints via map et générer dynamiquement les règles via mixin avancé. Livrable attendu : Refactoriser le système responsive en adoptant une configuration unique et générative pour tous les breakpoints.