Nichts zu konfigurieren. Cloud liefert den Provider und die Identität, und die Kommentar-Schaltfläche im Header erscheint, sobald eine Vorlage gespeichert ist.
Jeder Thread der Vorlage, jeweils mit seinen Antworten
create
Speichert einen Kommentar oder eine Antwort, signiert mit dem User-Claim des Tokens
update
Bearbeitet den Text eines Kommentars
delete
Entfernt einen Kommentar und bei einem Wurzelkommentar auch dessen Antworten
setResolved
Markiert einen Thread als gelöst oder öffnet ihn wieder
subscribe
Bindet den Echtzeit-Kanal von Cloud, sodass der Kommentar einer Kollegin während des Schreibens erscheint
Alle vier Mutationen sind aktiviert: Kommentar-Speicherung und ihre Echtzeit-Verteilung sind genau das, was die Plan-Funktion commenting bezahlt — es gibt also keine Cloud-Stufe, die einen Thread lesen, aber nicht darauf antworten kann.
Drei Bedingungen, von denen keine die andere impliziert:
comments: false schaltet die Funktion vollständig ab.
Die Plan-Funktion commenting muss gewährt sein.
Die Vorlage muss gespeichert sein. Cloud verankert einen Kommentar serverseitig, es muss also eine gespeicherte Vorlage geben, an der er hängt — die Kommentar-Schaltfläche erscheint vor dem ersten Speichern nicht.
js
const editor = await initCloud({ container: '#editor', auth: { url: '/api/templatical/token' }, comments: false, // aus, unabhängig vom Plan});
Cloud sendet bei jedem Schreibvorgang user_id / user_name / user_signature mit, entnommen aus dem user-Claim des Auth-Tokens und von seinem Backend geprüft. Daher nimmt initCloud()keinen user-Schlüssel an: Es füllt init({ user }) aus genau diesem Claim, und eine vom Browser gelieferte Identität könnte der vom Server geprüften nur widersprechen.
Ein Projekt, dessen Token-Endpunkt den user-Claim weglässt, erhält überhaupt keine Kommentar-Funktion — nicht verfügbar, niemals anonym.
Konfiguration und Events, innerhalb von initCloud() — nie der Speicher.
Ein Kommentar ist an eine Vorlagen-ID gebunden, die Cloud ausgestellt hat, und seine Autorenschaft wird vom Token von Cloud signiert, sodass der Schlüssel comments von initCloud()CommentsOptions akzeptiert — onCreated, onUpdated, onDeleted, onResolved und onUnresolved — statt eines vollständigen Providers:
Einen vollständigen Provider zu übergeben ist unproblematisch: list, create, update, delete, setResolved und subscribe werden mit einer Konsolenwarnung ignoriert, die sie namentlich nennt, während onCreated, onUpdated, onDeleted, onResolved und onUnresolved den Editor trotzdem erreichen. Ein comments-Provider aus einer OSS-Integration braucht beim Umzug zu Cloud keine Änderung — lassen Sie den Schlüssel genau so, wie er ist.
Bringen Sie Ihren eigenen Speicher mit init() mit — dort gehört Ihnen der gesamte Satz: Vorlagen, Versionsverlauf, Kommentare, Rendering.
useComments und useCommentListener liegen in @templatical/core und nehmen einen Provider entgegen. Der Adapter von Cloud ist createCloudCommentsProvider aus @templatical/core/cloud:
Kommentare
Kommentare sind ein offener Vertrag. Templatical Cloud implementiert ihn genauso, wie Ihr eigenes Backend es täte.
Nichts zu konfigurieren. Cloud liefert den Provider und die Identität, und die Kommentar-Schaltfläche im Header erscheint, sobald eine Vorlage gespeichert ist.
Der Adapter
listcreateupdatedeletesetResolvedsubscribeAlle vier Mutationen sind aktiviert: Kommentar-Speicherung und ihre Echtzeit-Verteilung sind genau das, was die Plan-Funktion
commentingbezahlt — es gibt also keine Cloud-Stufe, die einen Thread lesen, aber nicht darauf antworten kann.Verfügbarkeit
Drei Bedingungen, von denen keine die andere impliziert:
comments: falseschaltet die Funktion vollständig ab.commentingmuss gewährt sein.Autoren-Identität
Cloud sendet bei jedem Schreibvorgang
user_id/user_name/user_signaturemit, entnommen aus demuser-Claim des Auth-Tokens und von seinem Backend geprüft. Daher nimmtinitCloud()keinenuser-Schlüssel an: Es fülltinit({ user })aus genau diesem Claim, und eine vom Browser gelieferte Identität könnte der vom Server geprüften nur widersprechen.Ein Projekt, dessen Token-Endpunkt den
user-Claim weglässt, erhält überhaupt keine Kommentar-Funktion — nicht verfügbar, niemals anonym.Eigene Implementierung
Konfiguration und Events, innerhalb von
initCloud()— nie der Speicher.Ein Kommentar ist an eine Vorlagen-ID gebunden, die Cloud ausgestellt hat, und seine Autorenschaft wird vom Token von Cloud signiert, sodass der Schlüssel
commentsvoninitCloud()CommentsOptionsakzeptiert —onCreated,onUpdated,onDeleted,onResolvedundonUnresolved— statt eines vollständigen Providers:Einen vollständigen Provider zu übergeben ist unproblematisch:
list,create,update,delete,setResolvedundsubscribewerden mit einer Konsolenwarnung ignoriert, die sie namentlich nennt, währendonCreated,onUpdated,onDeleted,onResolvedundonUnresolvedden Editor trotzdem erreichen. Eincomments-Provider aus einer OSS-Integration braucht beim Umzug zu Cloud keine Änderung — lassen Sie den Schlüssel genau so, wie er ist.Bringen Sie Ihren eigenen Speicher mit
init()mit — dort gehört Ihnen der gesamte Satz: Vorlagen, Versionsverlauf, Kommentare, Rendering.Headless-Nutzung
useCommentsunduseCommentListenerliegen in@templatical/coreund nehmen einen Provider entgegen. Der Adapter von Cloud istcreateCloudCommentsProvideraus@templatical/core/cloud:Die vollständige reaktive Oberfläche steht im Kommentar-Leitfaden.