Chapitre 77 : CSS-in-JS : enjeux et intégration

Gestion dynamique du CSS via des bibliothèques JavaScript

Le CSS-in-JS représente l'un des changements de paradigme les plus radicaux dans le développement front-end moderne. En déplaçant la responsabilité du style du fichier .css vers le moteur JavaScript, il promet une résolution complète des problèmes de portée (scoping) et une intégration profonde avec l'état de l'application. Cependant, pour l'expert, le CSS-in-JS n'est pas une solution miracle, mais un arbitrage complexe entre expérience développeur (DX) et performance runtime.

Le Paradigme CSS-in-JS

1. Quoi

Le CSS-in-JS est un pattern de conception qui consiste à écrire les styles CSS directement au sein de fichiers JavaScript ou TypeScript. Contrairement aux CSS Modules qui isolent les classes au moment de la compilation, le CSS-in-JS utilise souvent un moteur de runtime pour générer des classes uniques, calculer des valeurs dynamiques basées sur des props et injecter ces styles dans le DOM via des balises {'<style>'}.

On distingue aujourd'hui deux grandes familles :

• Runtime CSS-in-JS : (ex: styled-components, emotion) Les styles sont calculés et injectés pendant l'exécution du code dans le navigateur.
• Zero-Runtime / Static CSS-in-JS : (ex: vanilla-extract, Linaria) Le JavaScript est utilisé pour définir les styles, mais un plugin de build extrait tout le CSS dans des fichiers statiques .css avant le déploiement.

2. Pourquoi

L'adoption du CSS-in-JS dans les projets d'envergure répond à des besoins architecturaux précis :

• Scoping Absolu : Plus aucun risque de collision de noms. Chaque composant possède ses propres styles, rendant le "cascade" du CSS prévisible et contrôlé.
• Co-location : Le style et la logique du composant résident dans le même fichier. Cela réduit la charge cognitive lors de la maintenance.
• Dynamisme Typé : L'utilisation de TypeScript permet de contraindre les valeurs de styles (ex: limiter les couleurs à une palette définie dans le thème) et de lier les styles directement aux props du composant.
• Dead Code Elimination : Si un composant JS est supprimé, son CSS associé disparaît automatiquement, contrairement aux fichiers CSS globaux où le nettoyage est manuel et risqué.

3. Comment

A. Syntaxe de base (Runtime)

Voici l'approche classique avec styled-components :

import styled from 'styled-components';

// Création d'un composant stylisé
const Button = styled.button`
  background: ${props => props.primary ? 'blue' : 'gray'};
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 4px;
  cursor: pointer;

  &:hover {
    filter: brightness(1.1);
  }
`;

// Utilisation
export const App = () => (
  <div>
    <Button primary>Action Principale</Button>
    <Button>Action Secondaire</Button>
  </div>
);

B. Cas concret : Design System Typé et Thémisé

Dans un environnement expert, on ne définit pas de valeurs "en dur". On utilise un ThemeProvider et des interfaces TypeScript pour garantir la cohérence visuelle.

import React from 'react';
import styled, { ThemeProvider, DefaultTheme } from 'styled-components';

// 1. Définition du contrat du thème
interface AppTheme {
  colors: {
    primary: string;
    secondary: string;
    danger: string;
    background: string;
  };
  spacing: (unit: number) => string;
}

// On étend DefaultTheme pour le typage global de styled-components
declare module 'styled-components' {
  export interface DefaultTheme extends AppTheme {}
}

const lightTheme: AppTheme = {
  colors: {
    primary: '#007bff',
    secondary: '#6c757d',
    danger: '#dc3545',
    background: '#ffffff',
  },
  spacing: (unit) => `${unit * 8}px`,
};

// 2. Composant hautement dynamique
interface CardProps {
  variant: 'elevated' | 'flat';
  isActive: boolean;
}

const Card = styled.div<CardProps>`
  background: ${props => props.theme.colors.background};
  padding: ${props => props.theme.spacing(2)};
  border: 2px solid ${props => props.isActive ? props.theme.colors.primary : 'transparent'};
  
  box-shadow: ${props => props.variant === 'elevated' 
    ? '0 4px 6px rgba(0,0,0,0.1)' 
    : 'none'};
    
  transition: all 0.2s ease-in-out;
`;

export const Dashboard = () => (
  <ThemeProvider theme={lightTheme}>
    <Card variant="elevated" isActive={true}>
      Contenu de la carte
    </Card>
  </ThemeProvider>
);

C. Limitations et Coûts

Le CSS-in-JS n'est pas gratuit. Ses limitations sont principalement liées aux performances :

1. Le "Runtime Tax" : Chaque fois qu'une prop change, le moteur doit :
   • Calculer le nouveau style.
   • Générer un hash unique pour la classe.
   • Vérifier si ce style existe déjà dans le DOM.
   • Injecter la nouvelle règle CSS. Cela peut provoquer des lags sur des composants qui se mettent à jour fréquemment (ex: animations, sliders).
2. Bundle Size : L'ajout d'une bibliothèque comme emotion ou styled-components ajoute quelques dizaines de Ko au bundle JS.
3. Complexité SSR : Pour éviter le "Flash of Unstyled Content" (FOUC), le serveur doit collecter tous les styles utilisés pendant le rendu et les injecter dans le HTML initial, ce qui complexifie la configuration du serveur (Next.js, Remix).

4. Zone de Danger

❌ Erreur fatale : Définir un composant stylisé à l'intérieur d'un composant de rendu.

// ❌ À NE JAMAIS FAIRE
const MyComponent = ({ color }) => {
  // Le composant est recréé à CHAQUE rendu !
  // Le navigateur doit ré-injecter le style et recalculer le layout.
  const StyledDiv = styled.div`
    color: ${color};
  `;

  return <StyledDiv>Bonjour</StyledDiv>;
};

✅ Bonne pratique : Définir le composant à l'extérieur et passer les valeurs via des props.

// ✅ CORRECT
const StyledDiv = styled.div<{ color: string }>`
  color: ${props => props.color};
`;

const MyComponent = ({ color }) => {
  return <StyledDiv color={color}>Bonjour</StyledDiv>;
};

Cycle de vie du Runtime CSS-in-JS

Cycle de vie du Runtime CSS-in-JS

Analyse Comparative : Runtime vs Zero-Runtime

Pour un expert, le choix entre runtime et zero-runtime dépend de la nature de l'application.

Critère	Runtime (Styled-components)	Zero-Runtime (Vanilla Extract)
Performance	Overhead CPU au runtime	Performance native (CSS statique)
Flexibilité	Totale (accès à tout l'état JS)	Limitée (calculs au build time)
Bundle JS	Plus lourd (+ runtime)	Plus léger
CSS Final	Injecté dynamiquement	Fichier .css classique
Typage	Excellent	Exceptionnel (Type-safe CSS)

Le Zero-Runtime utilise des fonctions JS pour générer des classes, mais ces fonctions sont exécutées durant l'étape de build. Le résultat est un fichier CSS standard. C'est l'approche privilégiée pour les sites à fort trafic ou les applications où le LCP (Largest Contentful Paint) est critique.

Questions clés

1. Pourquoi le CSS-in-JS peut-il ralentir le rendu d'une application React ?

Découvrir la réponse

Le ralentissement provient du processus de "serialization". Le moteur doit transformer des objets JS ou des template literals en chaînes CSS, calculer un hash pour éviter les collisions, et manipuler le DOM pour injecter les styles. Si cela arrive dans une boucle de rendu rapide (ex: 60fps), cela sature le thread principal.

2. Comment gérer le Server-Side Rendering (SSR) avec le CSS-in-JS ?

Découvrir la réponse

Il faut utiliser un mécanisme de "Style Sheet Collector". Pendant le rendu côté serveur, la bibliothèque enregistre tous les styles sollicités. Ces styles sont ensuite extraits et insérés dans une balise {'<style>'} dans le <head> du document HTML envoyé au client, évitant ainsi que la page ne s'affiche sans style pendant la première seconde.

3. Quelle est la différence fondamentale entre CSS Modules et CSS-in-JS ?

Découvrir la réponse

Les CSS Modules sont une solution de build : ils renomment les classes pour les rendre uniques, mais le CSS reste dans des fichiers séparés et statiques. Le CSS-in-JS (runtime) déplace la logique de génération du style dans le navigateur, permettant un lien direct et dynamique entre les props JS et les propriétés CSS.

4. Quand devrais-je préférer Vanilla Extract à Styled-components ?

Découvrir la réponse

Privilégiez Vanilla Extract pour des projets où la performance est primordiale, pour des bibliothèques de composants distribuées (pour éviter d'imposer un runtime aux utilisateurs) ou lorsque vous souhaitez bénéficier du typage TypeScript strict sans payer le coût CPU du runtime.

Mise en pratique

Exercice 1 : Reproduction guidée

Objectif : Créer un composant Alert stylisé qui change de couleur selon un niveau de sévérité (info, warning, error).

• Utilisez styled-components.
• Le composant doit accepter une prop severity.
• Les couleurs doivent être définies dans un objet de configuration simple.

Découvrir la solution commentée

import styled from 'styled-components';

const severityColors = {
  info: '#d1ecf1',
  warning: '#fff3cd',
  error: '#f8d7da',
};

const AlertBox = styled.div<{ severity: 'info' | 'warning' | 'error' }>`
  padding: 1rem;
  border-radius: 8px;
  border: 1px solid #ccc;
  // Accès dynamique à la config via la prop
  background-color: ${props => severityColors[props.severity]};
  color: #333;
  font-family: sans-serif;
`;

export const Alert = ({ severity, children }: { severity: 'info' | 'warning' | 'error', children: React.ReactNode }) => (
  <AlertBox severity={severity}>
    {children}
  </AlertBox>
);

Exercice 2 : Adaptation

Objectif : Étendre le système de thémisation pour supporter un "Dark Mode" commutable.

• Implémentez deux objets de thème (lightTheme, darkTheme).
• Créez un état isDarkMode pour basculer entre les deux.
• Assurez-vous que vos composants stylisés utilisent les variables du thème et non des couleurs fixes.

Découvrir la solution commentée

import React, { useState } from 'react';
import styled, { ThemeProvider } from 'styled-components';

const lightTheme = { bg: '#fff', text: '#000' };
const darkTheme = { bg: '#333', text: '#fff' };

const Container = styled.div`
  background: ${props => props.theme.bg};
  color: ${props => props.theme.text};
  height: 100vh;
  transition: all 0.3s ease;
`;

export const ThemeSwitcher = () => {
  const [dark, setDark] = useState(false);

  return (
    <ThemeProvider theme={dark ? darkTheme : lightTheme}>
      <Container>
        <h1>Mode {dark ? 'Sombre' : 'Clair'}</h1>
        <button onClick={() => setDark(!dark)}>Basculer</button>
      </Container>
    </ThemeProvider>
  );
};

Exercice 3 : Conception

Objectif : Concevoir un système de "Spacing" typé pour éviter les valeurs magiques dans tout le projet.

• Créez une fonction de spacing dans le thème qui accepte un multiplicateur (ex: spacing(1) = 8px, spacing(2) = 16px).
• Appliquez ce système à un composant Stack (un conteneur qui gère l'espacement entre ses enfants via une prop gap).
• Utilisez TypeScript pour garantir que le gap est un nombre entier.

Découvrir la solution commentée

import styled, { ThemeProvider } from 'styled-components';

interface AppTheme {
  spacing: (unit: number) => string;
}

const theme: AppTheme = {
  spacing: (unit) => `${unit * 8}px`,
};

// Le composant Stack utilise la fonction du thème pour calculer le gap
const Stack = styled.div<{ gap: number }>`
  display: flex;
  flex-direction: column;
  gap: ${props => props.theme.spacing(props.gap)};
`;

export const Layout = () => (
  <ThemeProvider theme={theme}>
    <Stack gap={3}> {/* 3 * 8px = 24px */}
      <div>Élément 1</div>
      <div>Élément 2</div>
      <div>Élément 3</div>
    </Stack>
  </ThemeProvider>
);