MallaDocs
AccueilDémarrage rapideOuvrir Malla

Rendu et runtime

Un seul moteur de rendu pour le canevas et le site, la publication par instantané, les îlots et le runtime client.

Guide développeur

@malla/renderer est une fonction pure qui transforme des documents en HTML et en CSS. Elle tourne dans les cadres du canevas, dans le Worker sites et dans les tests : c'est pourquoi l'éditeur correspond à la production.

ts
renderPage({ doc, components, classes, tokens, site, data, user? })
  → { html, css, runtime: RuntimeManifest }

Publication par instantané

Publication : O(1) quelle que soit la taille du site
apiPOST /sites/:id/publish vérifie le rôle et le forfait.
Instantanésnapshot.json + CSS partagé compilé, vers R2.
WorkflowsLes workflows serveur vers KV, par environnement.
BasculePointeur d'hôte dans KV → nouveau publishId.

Une publication écrit un instantané immuable (documents des pages et des composants, classes, jetons, SEO, manifeste) et bascule un seul pointeur : la publication est donc instantanée et atomique, et revenir en arrière n'est qu'une autre bascule. La fenêtre de publication et POST /sites/:siteId/rollback la ramènent à l'une des 50 publications les plus récentes de l'environnement (voir Retour arrière) ; les éléments du CMS, les ressources et les autres données en direct ne reviennent pas en arrière. Les pages critiques sont prérendues pour ne jamais être froides.

Rendu à la demande

Une requête vers un site publié
Recherche de l'hôteKV : hôte → site, environnement, publishId.
AccèsRègle de la page vérifiée à chaque requête.
CacheSuccès : Cache API ou réécriture depuis R2.
RenduÉchec : renderPage à partir de l'instantané.
  • Les pages statiques sont rendues une fois par publication et mises en cache pour toujours sous des clés qui incluent le publishId.
  • Les pages serveur exécutent les requêtes serveur et sont rendues à chaque requête à l'edge, avec un TTL court.
  • Les changements du CMS incrémentent une révision par collection ; seules les pages qui en dépendent sont rendues à nouveau.
  • /api/* et /_auth/* vont au runner ; /api/_q/* (requêtes client) et /api/_forms/* restent dans sites.

Runtime d'îlots

La structure publiée est du HTML statique. Seuls les textes, attributs et styles liés ainsi que les listes répétées changent : @malla/runtime se résume donc à @vue/reactivity + l'interpréteur d'expressions partagé + un patcheur de DOM minimal. Pas de DOM virtuel, pas d'hydratation complète, moins de 25 Ko compressé avec gzip. Il ne se charge que sur les pages qui ont des liaisons, des formulaires ou des workflows client ; GSAP est un chunk séparé, chargé uniquement pour les interactions.

  • Le moteur de rendu émet un manifeste des îlots à hydrater.
  • Les pages rendues à chaque requête intègrent le visiteur dans le manifeste ; les pages en cache appellent /_auth/me une seule fois au démarrage, et seulement si quelque chose lit user.
  • La navigation entre pages utilise le préchargement des Speculation Rules et les View Transitions, pour une sensation d'application.

Dans le canevas

Chaque plan de travail est une iframe en bac à sable sur une origine distincte, qui dialogue avec l'éditeur via un protocole postMessage typé : init, patch avec des ops, mesure, test de clic (hit-test). Les patchs ne touchent que le nœud modifié et sa règle CSS.