Construire un design system Liquid Glass avec React

Commencer par les décisions, pas les composants

Inventoriez les usages : navigation flottante, carte interactive, popover, panneau modal. Pour chacun, notez densité, niveau de profondeur et capacités d’interaction. Cette matrice révèle les vrais tokens. Trois niveaux bien définis valent mieux que douze variantes nommées d’après des pages.

Les tokens de matière couvrent remplissage, blur, saturation, bordure, reflet et ombre. Les tokens de mouvement couvrent durée et courbe. Les tokens sémantiques associent ensuite ces valeurs à surface-base, surface-raised et surface-focus. Un thème peut changer les valeurs sans modifier les composants.

Une primitive sans sémantique imposée

Créez une primitive GlassSurface qui accepte un élément ou un slot, une profondeur et un mode interactif. Elle ne devient pas automatiquement bouton. Elle fournit classes, variables et décorations, tandis que l’appelant conserve le bon élément HTML.

tsx
type GlassDepth = "base" | "raised" | "focus";

type GlassSurfaceProps = React.ComponentPropsWithoutRef<"div"> & {
  depth?: GlassDepth;
  interactive?: boolean;
};

Évitez les props qui reproduisent chaque token. Si un produit a besoin de blur={17}, le système a probablement raté une variante ou accepté une exception non documentée.

Composer plutôt qu’hériter

Construisez ensuite GlassCard, GlassNav et GlassPopover par composition. Chaque composant ajoute sa sémantique, ses espacements et ses contraintes. Le popover gère focus et fermeture; la carte ne le fait pas. La navigation garantit une cible suffisante; la surface ignore le métier.

Les interactions au pointeur restent une capacité optionnelle. Chargez le gestionnaire seulement pour un pointeur fin et une variante interactive. Les coordonnées passent par des variables CSS, conformément à l’architecture React dédiée.

Gouvernance des variantes

Documentez quand utiliser chaque profondeur, avec un contre-exemple. Ajoutez une règle : aucune nouvelle valeur de blur dans une feature. Toute évolution passe par les tokens et doit être testée dans clair, sombre, contraste renforcé et fallback sans filtre.

Exposez les alt localisés au niveau des données éditoriales, pas dans la primitive visuelle. Une image de carte reçoit le texte de la langue active; un reflet CSS demeure décoratif.

Tests utiles

Les tests unitaires vérifient le bon élément, les classes de variante et l’absence de rôle artificiel. Les tests d’interaction couvrent clavier, focus et préférence réduite. Les captures visuelles comparent thèmes et fallbacks. Enfin, un budget performance surveille le nombre de surfaces et évite une accumulation silencieuse.

Testez aussi la suppression du système : si remplacer GlassSurface par une surface opaque casse la mise en page, le composant contient trop de responsabilités.

Adoption progressive

Commencez par une zone visible mais bornée, mesurez, puis migrez les usages similaires. Ne convertissez pas toutes les cartes. Les surfaces opaques restent essentielles pour les contenus longs et denses. Publiez une note de migration qui associe anciens styles et nouvelles variantes.

Cette architecture boucle la série : fondamentaux visuels, CSS progressif, interactions typées et critères de qualité. Le résultat n’est pas une collection d’effets, mais un langage d’interface durable.