Rendu côté serveur

@sixtyfold/ssr exécute le même rendu TypeScript sur un canvas serveur minimal. Il n’importe pas les globals canvas du DOM, ne crée pas de workers navigateur et n’anime pas. La sortie PNG réelle des graphiques Line et Stock est continuellement vérifiée dans Node.js, Bun et Deno.

Installez le paquet SSR et une implémentation Canvas2D adaptée à votre runtime. L’ensemble de compatibilité vérifié utilise @napi-rs/canvas, mais Sixtyfold ne l’impose pas comme dépendance de bibliothèque.

La référence générée répertorie précisément les fonctions SSR, les options de rendu et les types de canvas neutres au runtime.

pnpm add @sixtyfold/ssr@next @napi-rs/canvas

import { createCanvas } from "@napi-rs/canvas";
import { renderLineChartSSR } from "@sixtyfold/ssr";

const width = 1200;
const height = 630;
const canvas = createCanvas(width * 2, height * 2);

renderLineChartSSR(
  canvas,
  data,
  {
    animated: false,
    chartBackground: "#081018",
    series: [{ color: "#65d6ff", width: 2 }],
    axis: { bottom: { format: "time" } },
  },
  { width, height, dpr: 2 },
);

const png = await canvas.encode("png");

L’implémentation du canvas est responsable de l’encodage des images.

Runtimes serveur vérifiés

La suite de compatibilité épingle actuellement ces cibles CI :

Ce sont des cibles CI reproductibles, pas des déclarations de version minimale. Chaque runtime rend des fixtures Line et Stock de façon déterministe sans accès réseau. Le gate compare les pixels du tracé à une référence visuelle épinglée et exige que chaque libellé nommé produise des pixels visibles à son ancre de mise en page exacte dans une région bornée ; il valide aussi les signatures PNG, les dimensions et la sortie encodée. Il n’épingle ni les largeurs de glyphes ni les ratios d’encre dépendant des polices. Les PNG sont conservés comme artefacts CI inspectables. Avant une publication, la référence visuelle Node est répétée sous Ubuntu, macOS et Windows.

Node.js et Bun exécutent le même module directement :

node app.mjs
bun app.mjs

Deno requiert un arbre local node_modules et des permissions explicites pour l’addon canvas Node-API :

deno run \
  --allow-read \
  --allow-env \
  --allow-ffi \
  --allow-sys=homedir \
  --node-modules-dir=manual \
  app.mjs

Ajoutez --allow-write=<output-directory> uniquement lorsque l’application écrit des images encodées sur le disque. Voir la source de vérification du runtime, la prise en charge de Node-API par Bun et les conseils de Deno sur les modules natifs.

Configuration prise en charge

Le SSR accepte des options visuelles destinées au renderer : padding, direction, grid, axes, background, sélecteur de plage, style des infobulles, style du crosshair, labels, overlays, séries en lignes/LOD, chandeliers boursiers, indicateurs, profil de volume, lignes de prix et marqueurs. Les callbacks exclusifs au navigateur, contrôles DOM, interaction par pointeur et workers sont volontairement absents.

Réglez animated: false pour plus de clarté même si le rendu statique se termine immédiatement. Utilisez le même width, height et dpr dans les tests et en production pour éviter des différences de snapshot.

Injection de canvas indépendante du runtime

Lorsque l'appelant ne possède pas déjà le canvas, fournissez createCanvas dans SSRRenderOptions. Il reçoit les dimensions du backing‑store. L'objet renvoyé doit fournir width, height et getContext("2d") avec les méthodes Canvas2D utilisées par le renderer.

Sortie déterministe

• Verrouillez l’implémentation du canvas et les polices dans l’image de rendu.
• Fournissez une famille de polices explicite si le serveur ne propose pas la pile du navigateur.
• Évitez les overlays depuis des URL distantes pendant le rendu des requêtes ; résolvez et mettez en cache les assets avant le rendu.
• Conservez stables les tableaux d’entrée, la taille du graphique, le DPR, la locale, le fuseau horaire et les options.