Builder visuel

Ce que le builder ne fait pas. Pas de marges, padding, taille de police, polices, ombres, grilles. Ces réglages sont volontairement absents pour éviter les destructions visuelles. L'auteur du template reste le seul décideur de la grille et de la typographie.

Onglet Avancé (Phase 4)

L'onglet Avancé contient pour l'instant un seul réglage : la balise dynamique. Sur un élément texte, l'utilisateur peut choisir parmi h1, h2, h3, h4, h5, h6, p et span. Le changement de balise est stocké dans overrides.{key}.tags_html.

Côté preview, le remplacement de balise est fait dans le DOM via une fonction swapTagPreserveContent(node, newTag) qui :

1. Clone l'élément cible dans la nouvelle balise.
2. Recopie l'intégralité des attributs (sauf ceux interdits par la nouvelle balise).
3. Re-parente les enfants et conserve les data-cms.
4. Émet un event cms:tag-swapped pour resynchroniser l'inventaire.

function swapTagPreserveContent(node, newTag) {
  const replacement = document.createElement(newTag);
  for (const attr of node.attributes) {
    replacement.setAttribute(attr.name, attr.value);
  }
  while (node.firstChild) replacement.appendChild(node.firstChild);
  node.replaceWith(replacement);
  return replacement;
}

Phase 5 — Polish et ergonomie

La cinquième phase a regroupé les retouches qui transforment un prototype fonctionnel en outil quotidien.

• Raccourcis clavier : Ctrl+S force la sauvegarde immédiate, Esc ferme la sidebar, Ctrl+Z annule la dernière modification (historique en mémoire 50 étapes).
• Persistance de la sélection : au rechargement de l'iframe (changement de viewport ou rebuild), la sélection courante est retrouvée via le cmsKey stocké dans le store Zustand.
• Badge « modifié » : chaque élément de l'inventaire dont la clé apparaît dans overrides est marqué d'un point orange. La liste des éléments modifiés est aussi disponible dans le panneau latéral droit.
• Indicateur de sauvegarde : trois états dans la topbar du builder — Sauvegardé (par défaut), Modifications non sauvegardées (debounce en attente), Sauvegarde… (PUT en cours).
• Responsive preview : trois presets de largeur d'iframe (mobile 375 px, tablette 768 px, desktop pleine largeur) pour vérifier le rendu sans quitter le builder.

Mécanisme applyUpdate

La fonction applyUpdate(cmsKey, patch) est le point d'entrée unique côté preview-overlay.js pour modifier le DOM en réponse à un message du parent. Elle gère les cas suivants :

Patch	Cible DOM	Action
{ text }	élément texte	node.textContent = patch.text
{ html }	élément html	node.innerHTML = sanitize(patch.html)
{ src }	img / video / iframe	node.src = patch.src + reload si vidéo
{ alt, title }	img	setAttribute respectifs
{ href, target, rel }	a	setAttribute respectifs
{ style }	tout élément	Object.assign(node.style, patch.style)
{ tag }	tout élément	swapTagPreserveContent(node, patch.tag)

Toute combinaison de ces clés peut être passée dans un seul patch (par exemple { text, style, tag } pour une modification atomique). L'ordre d'application est : tag en premier (sinon la référence DOM change), puis style, puis le contenu.

Stockage des overrides

Les overrides sont persistés dans la colonne JSON overrides de la table pages (ou pages cocon, ou articles). La structure est plate, indexée par cmsKey.

{
  "hero.title": {
    "text": "Bienvenue au Labo du Yeti",
    "style": { "color": "#0F1B3D", "textAlign": "center" },
    "tags_html": "h1"
  },
  "hero.cta": {
    "text": "Démarrer maintenant",
    "style": { "backgroundColor": "#F58220", "color": "#FFFFFF" },
    "href": "/contact"
  },
  "hero.bg": {
    "src": "/uploads/media/hero-2026.webp",
    "alt": "Atelier vu de l'intérieur"
  }
}

Le serveur applique les overrides au moment du rendu : pour chaque clé présente, il retrouve le ou les nœuds correspondants via data-cms-* avec Cheerio, et applique les patchs dans le même ordre que applyUpdate. Le résultat est mis en cache jusqu'à la prochaine sauvegarde.