Gespeicherte Blöcke

Gespeicherte Blöcke sind 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 — diese Funktion ist standardmäßig an. Cloud stellt den Provider bereit, und die Bibliotheksleiste erscheint in der Seitenleiste.

Der Adapter

Methode	Cloud
list	Alle gespeicherten Blöcke des Projekts, in der Reihenfolge, die Cloud liefert
create	Speichert einen Block mit Namen und optionaler Kategorie
update	Benennt um oder ändert die Kategorie
delete	Entfernt ihn aus dem Projekt

Eine Bibliothek pro Projekt, geteilt von allen Beteiligten — ein Block, den eine Kollegin speichert, liegt beim nächsten Öffnen im Browser aller anderen. Genau das hat kein OSS-Gegenstück: nicht der Speicher, sondern die Tatsache, dass er bereits geteilt ist.

Alle vier sind aktiv. Clouds Bibliothek ist an die Planfunktion savedModules gebunden.

Eigene Implementierung

Das geht, und initCloud() nimmt dies als vollständigen Ersatz an, genauso wie testEmail und media. Der Schlüssel hat denselben Typ wie bei init(), dazu eine dritte Form, die nur an diesem Einstiegspunkt existiert: Clouds Bibliothek behalten und eigene Event-Handler hinzufügen.

await initCloud({ container, auth });                             // Clouds Bibliothek
await initCloud({ container, auth, savedBlocks: { onCreated } }); // Clouds Bibliothek, plus Ihre Events
await initCloud({ container, auth, savedBlocks: mine });          // Ihre eigene, auf Cloud
await initCloud({ container, auth, savedBlocks: false });         // aus

Cloud unterscheidet sie an list, nie daran, ob der Wert ein Objekt ist: Alles mit einem funktionierenden list ersetzt Clouds Speicher vollständig, und alles andere — true, false, ein reines Events-Objekt — behält Clouds eigenen Speicher und leitet dessen Events an ihn weiter.

Das lässt sich gefahrlos mischen, weil Cloud die Bibliothek nie eigenständig nutzt: Ein gespeicherter Block wird auf die Arbeitsfläche kopiert und sonst nirgends gelesen — es gibt also keinen zweiten Speicher, der widersprechen könnte.

Ein Provider, den Sie übergeben, ist nicht plangebunden — die Planfunktion lizenziert Clouds Speicher, nicht die Oberfläche des Editors. Ein reines Events-Objekt bleibt plangebunden, denn Clouds eigener Speicher erledigt die Arbeit weiterhin.

Events

savedBlocks: {
  onCreated: (block) => {},
  onUpdated: (block) => {},
  onDeleted: (block) => {},
}

Dieselben Events wie im offenen Vertrag, ausgelöst unabhängig davon, ob der dahinterliegende Speicher Clouds eigener ist oder Ihr eigener.

Headless-Nutzung

Die REST-Methoden behalten ihre ursprüngliche module-Benennung — listModules, createModule, updateModule, deleteModule. Siehe Headless-API.