ADR 002
StatutStatus ActifActive
DateDate 2026-05-28
DécideursDecision makers Design System Lead, Tech Lead

ADR-002 — Choix de Lit pour les Web Components

Date : 2026-05-28 Statut : ✅ Actif Décideurs : Design System Lead, Tech Lead Type: contract Chemin logique: decisions/ADR-002-lit-web-components.md Lecture avant: AGENTS.md, DESIGN.md, .claude/rules/development.md Relations: .claude/rules/development.md, guidelines/components/, decisions/ADR-001-trois-niveaux-tokens.md


Contexte

Le système de design doit servir plusieurs équipes utilisant des frameworks différents (React, Angular, Vue, vanilla JS). La question posée était :

Comment livrer des composants UI qui fonctionnent partout sans imposer un framework ?

Deux contraintes non négociables orientaient le choix :

1. Portabilité universelle — un composant ds-button doit fonctionner identiquement dans une app React, Angular, ou une page HTML statique, sans adaptation. 2. Contrat lisible par machine — les composants doivent exposer leurs propriétés (variant, disabled, loading) de manière structurée pour que les agents IA puissent les inspecter et les générer correctement.

Les Web Components natifs (standard W3C) répondent à la contrainte 1 nativement. Mais les écrire en vanilla est verbeux et ne gère pas la réactivité élégamment. Un outil de bas niveau était nécessaire pour réduire le boilerplate sans ajouter de dépendance lourde.


Décision

Adoption de Lit (Google) comme couche d'abstraction légère sur les Web Components natifs.

Lit n'est pas un framework — c'est une bibliothèque minimaliste (~5 kb gzippé) qui ajoute :

Les composants compilés sont de vrais Custom Elements W3C — Lit disparaît à l'exécution du point de vue des consommateurs.


Alternatives rejetées

AlternativeRaison du rejet
Web Components vanilla (sans Lit)Verbosité excessive : gestion manuelle du Shadow DOM, des attributs observés, de la réactivité. Coût de maintenance élevé pour chaque composant.
React (composants exportés)Couplage au framework. Un composant React ne s'utilise pas dans Angular sans wrapper. Contraire au principe de portabilité universelle.
Stencil.jsPipeline de build plus complexe, génération de code spécifique par framework. Ajoute une étape de compilation que Lit n'impose pas.
Angular ElementsDépendance à Angular dans les bundles. Taille trop importante pour un usage multi-framework.
Vue web componentsMême problème que Angular Elements — le runtime Vue est embarqué.
Bibliothèque de composants existante (MUI, Radix, etc.)Ces bibliothèques sont des implémentations, pas des systèmes de tokens. Elles imposent leurs conventions visuelles et cassent la souveraineté du système de design.

Conséquences

Pour les développeurs consommateurs :

Pour les agents IA :

les variantes autorisées sans parser du CSS ou du JSX

composant en suivant le template de .claude/rules/development.md

Pour la gouvernance des tokens :

sans passer par les CSS Custom Properties (var(--ds-[token]))

l'extérieur autrement qu'en modifiant une CSS Custom Property définie dans le système

Coût accepté :

Lit suit les standards W3C et que les composants resteraient fonctionnels sans Lit


Incidents ou déclencheurs

Aucun incident en production. Décision prise en amont lors de la conception de l'architecture. Référence : présentation de Web Components + Lit à l'AI Design Systems Conference 2026 (Into Design Systems) — validation externe du pattern pour les systèmes agentiques.

← ADR-001 ADR-003 →