docs interactives · architecture
Ce que fait site-factory entre « un visiteur demande la home » et « du HTML stylé arrive ». Faites défiler : le schéma suit votre lecture. Version écrite : référence ch. 4.
La requête arrive sur une route Next.js. Pour la home, c'est un composant serveur
minuscule : il cherche la page au slug / dans la composition et délègue
tout à l'assembleur.
Un simple objet TypeScript décrit le site entier : le chrome (variantes du header et du footer), les pages, et pour chaque page la liste ordonnée des sections avec leur variante — plus les groupes d'animation. Dans un projet client, ce fichier est figé par le bake à partir des choix du playground.
src/blocks/composition.ts
Il traduit chaque id de section en composant via son registre
SECTIONS, découpe la liste selon les groupes d'animation, et enveloppe le
tout dans le chrome partagé (header + footer).
Chaque section passe dans une SectionShell : largeur (pleine ou contenue),
fond (doux / marque / mesh), séparateurs SVG. La décoration est externe — la
section n'en sait rien.
Le composant serveur de la section (ex. le hero) demande son contenu… mais jamais à
Sanity ni à Prismic directement : il parle au contrat — l'interface
CmsClient. Un import direct d'un CMS ici casserait le lint, donc la CI.
Le contrat charge l'implémentation désignée par NEXT_PUBLIC_CMS_PROVIDER —
par import dynamique : le code de l'autre provider n'est jamais embarqué.
Changer de CMS, c'est changer cette variable.
Le document brut du CMS (format propriétaire : _id, uid, rich
text natif…) est projeté vers la forme du contrat : id, slug,
updatedAt, rich text opaque. Passé cette douane, plus aucun format
propriétaire ne circule dans le site.
La variante choisie reçoit les données et produit le HTML. Elle ne connaît aucune
couleur, aucun rayon : uniquement des tokens (bg-brand,
rounded-card, py-section) — c'est le design actif qui décide
des valeurs. Voilà pourquoi le même bloc peut être brutalist, glass ou editorial sans
changer une ligne.