Versionsverlauf

Der Versionsverlauf ist ein offener Vertrag. Templatical Cloud implementiert ihn genauso, wie Ihr eigenes Backend es täte.

const editor = await initCloud({ container: '#editor', auth: { url: '/api/token' } });

Nichts zu konfigurieren. Cloud stellt den Provider bereit, und das Verlaufs-Steuerelement im Header erscheint, sobald eine Vorlage erstellt oder geladen wurde.

Der Adapter

Methode	Cloud
list	Liefert alle Versionen der Vorlage — samt Inhalt, sodass das Blättern durch den Verlauf nie wartet
get	Holt den Inhalt einer einzelnen Version
create	Zeichnet auf Anforderung eine Version auf
restore	Ein atomarer, protokollierter Server-Endpunkt

Beide Mutationen sind aktiviert: Versionsspeicher ist Teil dessen, wofür der Tarif bezahlt wird. Es gibt also keine Cloud-Stufe, die den Verlauf auflisten, aber nicht wiederherstellen kann.

Automatische Versionen

Der Vorlagen-Adapter von Cloud zeichnet sie als Teil seines eigenen save auf, gedrosselt auf höchstens eine pro Minute. Das ist die Regel des Vertrags für jede Implementierung — wer den Speicher besitzt, bestimmt die Aufbewahrung. Ein Speichern, das nur die Vorlage umbenennt, zeichnet nichts auf.

Eigene Implementierung

Nicht der Speicher. Eine Version ist an eine von Cloud ausgestellte Vorlagen-ID gebunden, und der templates-Adapter von Cloud zeichnet bei jedem Speichern eine automatische Version auf, und dieselbe ID verankert zugleich Zusammenarbeit, Kommentare, KI-Umformulierung, Bewertung und den serverseitigen Export — deshalb nimmt initCloud() den Schlüssel templates für seine Konfiguration und Events entgegen, nie für einen vollständigen Provider. Ein selbst bereitgestellter Verlauf würde die Oberfläche steuern, während Cloud weiter Versionen in den eigenen Speicher schreibt: zwei Speicher, einer davon unsichtbar und kostenpflichtig.

versionHistory folgt derselben Form. initCloud({ versionHistory }) nimmt VersionHistoryOptions entgegen — onCreated, onRestored — und sonst nichts: keine Boolean-Form zum Abschalten, keine vollständige Provider-Form. Ein Wert mit list / get / create / restore hat diese Methoden weiterhin ignoriert, benannt in einer Konsolenwarnung, wobei nur seine Events übernommen werden.

await initCloud({
  container: '#editor',
  auth: { url: '/api/templatical/token' },
  versionHistory: {
    onRestored: (template) => navigate(`/templates/${template.id}`),
  },
});

Bringen Sie Ihren eigenen Speicher mit init() mit — dort gehört Ihnen der gesamte Satz: Vorlagen, Versionsverlauf, Rendering.

Events

versionHistory: {
  onCreated: (version) => {},
  onRestored: (template) => {},
}

Dieselben Events wie im offenen Vertrag.

Headless-Nutzung

import { createCloudVersionHistoryProvider } from '@templatical/core/cloud';
import { useVersionHistory } from '@templatical/core';

const history = useVersionHistory({
  provider: createCloudVersionHistoryProvider(authManager),
  getTemplateId: () => 'template-id',
});

await history.load();
await history.restore(history.versions.value[1].id);

Die zugrunde liegenden ApiClient-Methoden heißen getVersions, getVersion, createVersion und restoreVersion — siehe Headless-API.