On reçoit une maquette Figma avec des cartes alignées en rangée, des espacements variables selon les breakpoints, et un composant « container » qui doit s’étirer ou se replier selon le contexte. Le designer a pensé en flex. Le développeur ouvre son éditeur et commence à empiler des classes utilitaires.
Entre les deux, le design system est censé garantir la cohérence. En pratique, c’est là que flex extend entre en jeu, non pas comme une simple propriété CSS, mais comme un comportement à formaliser dans chaque composant réutilisable.
Lire également : Comment le plugin optimole facilite la gestion des médias de votre site WordPress
Flex extend comme primitive de composant, pas comme classe CSS isolée
La plupart des guides traitent flex extend sous l’angle de la mise en page : on parle de flex-grow, de flex-shrink, de raccourcis Tailwind. C’est utile, mais ça rate le vrai sujet quand on travaille dans un design system structuré.
Dans une architecture de composants (React, Vue, ou même des partials PHP pour WordPress), flex extend se formalise comme un jeu de props héritées du conteneur. On définit un composant Flex de base avec des valeurs par défaut (direction, alignement, gap), puis chaque variante étend ces props via un mécanisme de type extends FlexProps. Le composant enfant hérite du comportement flex du parent et peut surcharger uniquement ce qui change.
A lire aussi : Les avantages d'utiliser un vérificateur de site internet pour votre entreprise
Cette logique a une conséquence directe sur le code : au lieu de poser des classes utilitaires à la volée dans chaque page, on centralise le comportement dans un fichier de config du design system. Le développeur n’a plus à deviner si la carte produit utilise flex-grow: 1 ou flex-grow: 0, c’est défini une seule fois.
Formaliser les tokens flex dans votre fichier de config Tailwind ou CSS
Quand on utilise Tailwind, la tentation est forte de multiplier les classes dans le HTML : flex, flex-1, grow, shrink-0. Sur un projet avec trois pages, ça passe. Sur un design system partagé entre plusieurs équipes, l’absence de tokens flex génère des incohérences en quelques semaines.
La solution passe par le fichier tailwind.config (ou les custom properties CSS pour les projets sans framework utilitaire). On y déclare des tokens sémantiques qui encapsulent le comportement flex extend.
flex-card: un raccourci qui combineflex: 1 1 autoavec unmin-widthadapté au breakpoint mobile, utilisé sur tous les composants de type carte.flex-sidebar: un comportement où l’élément ne grandit pas (flex-grow: 0) mais conserve une largeur fixe, typique des navigations latérales.flex-content: l’élément principal qui absorbe l’espace restant (flex-grow: 1,flex-shrink: 1), avec unmin-width: 0pour éviter les débordements de texte.
Ces tokens deviennent la référence partagée entre le designer (qui les retrouve dans Figma sous forme de styles nommés) et le développeur (qui les applique via une classe unique). On réduit le nombre de décisions à prendre dans chaque page.
Risques de débordement et limites de flex extend sur des contenus réels
Sur la maquette, tout tient. Les textes font deux lignes, les images ont le bon ratio. En production, un titre de 80 caractères casse la grille flex. C’est un problème classique, et flex extend n’y échappe pas.
Le piège le plus fréquent est l’oubli du min-width: 0 sur les enfants flex. Par défaut, un élément flex ne rétrécit pas en dessous de la taille de son contenu. Si le contenu est un mot long ou une URL non coupée, l’élément déborde du conteneur. Les retours varient sur ce point selon les navigateurs, mais la règle de base reste la même : poser min-width: 0 (ou overflow: hidden) sur chaque enfant susceptible de recevoir du texte dynamique.
Autre cas concret : les composants imbriqués. Un conteneur flex qui contient un autre conteneur flex avec ses propres règles de flex-grow peut produire des résultats surprenants. Le comportement hérité du parent n’est pas toujours celui qu’on attend. Dans le design system, on documente explicitement le contexte d’usage de chaque composant flex : ce composant fonctionne en enfant direct d’un flex-row, pas dans un grid.
Gouvernance du design system : variantes partagées plutôt que forks locaux
Un développeur a besoin d’une carte légèrement différente pour une page spécifique. Plutôt que d’étendre le composant existant, il copie le code, modifie deux propriétés flex, et crée un composant local. Trois mois plus tard, on retrouve huit variantes de cartes dont six ne respectent plus les tokens du design system.
La règle à poser dès le départ : étendre une variante, jamais forker un composant. En pratique, cela signifie que le composant Flex de base accepte un ensemble de props documentées (direction, wrap, gap, grow), et que toute nouvelle variante passe par l’ajout d’une combinaison nommée dans le design system, pas par un fichier CSS local.
Cette gouvernance a un coût : chaque nouvelle variante doit être validée, nommée et documentée. Sur un projet WordPress avec plusieurs développeurs, on passe par un fichier de styles partagé (souvent un _tokens.css ou un objet dans le theme.json pour les thèmes blocs). Sur un projet React, c’est le Flex.variants.ts qui fait autorité.
Traduire les décisions Figma en code sans perte d’information
Le designer pose un auto-layout en mode « fill container » dans Figma. Le développeur traduit ça en flex: 1. Le problème, c’est que « fill container » dans Figma ne dit rien sur le flex-shrink ni sur le flex-basis. Chaque auto-layout Figma doit être mappé à un token flex précis dans la documentation, pas à une interprétation libre.
On recommande une table de correspondance simple :
| Comportement Figma | Token CSS / Tailwind |
| Fill container | flex-content (flex: 1 1 0%) |
| Hug contents | flex-hug (flex: 0 0 auto) |
| Fixed width | flex-fixed (flex: 0 0 [valeur]) |
Cette correspondance, intégrée dans la documentation du design system, supprime l’ambiguïté lors du passage de la maquette au code. Le développeur n’interprète plus, il applique le token qui correspond au comportement Figma.
L’intégration de flex extend dans un design system ne se résume pas à maîtriser les propriétés CSS. C’est un travail de formalisation : nommer les comportements, les documenter dans le fichier de config, poser des règles de gouvernance pour éviter la dérive. Un composant flex bien encadré dans le design system coûte du temps à mettre en place, mais évite des semaines de corrections sur les pages en production.
