CKEditor 5 autosave: return the promise that actually saves the document

Consider a fictional rehearsal note. The stage manager changes “Collect radios at reception” to “Collect radios at the lighting desk.” The editor remains open while the server is unavailable. A useful save indicator must distinguish that unsaved correction from an acknowledged server copy.

Connect the callback to your existing save service

In a configured CKEditor 5 build, include Autosave among the plugins and merge these options into the editor configuration:

const autosaveOptions = {
  autosave: {
    waitingTime: 1500,
    save(editor) {
      return persistRehearsalNote(editor.getData());
    }
  }
};

persistRehearsalNote is your application's existing asynchronous save operation. It must reject on failure and resolve only after its actual save contract succeeds. The fragment does not define an endpoint, authentication, record identity, concurrency control, or the editor's installation and license settings.

The important return value is the promise. This version loses it:

const incorrectAutosaveOptions = {
  save(editor) {
    persistRehearsalNote(editor.getData());
  }
};

That callback returns undefined. Keep return in the actual configuration, or use an async callback that awaits the operation. Do not catch a failure and turn it into a successful resolution merely to silence an error.

Separate a quiet typing interval from a confirmed save

waitingTime is measured in milliseconds. It reduces the number of save calls while someone types. It is not a deadline by which the network or database must finish. CKEditor also notes that its change observation does not compare the resulting data for equality; changes in the model can trigger work even when serialized data looks unchanged.

The plugin's pending state is useful when controlling navigation. CKEditor's example reads editor.plugins.get('PendingActions') and observes change:hasAny. That collection can also include other unfinished editor actions, such as uploads. Label it “Changes or uploads pending” if the indicator represents the whole collection. Do not infer a particular database revision solely from an empty collection. Autosave API

For a “Saved” timestamp, use the application save acknowledgement and associate it with the submitted document or revision. If the user types again while a save is in flight, acknowledging the earlier payload must not imply that the later words are already stored.

Test a delayed response and a failed response

On a development copy of the real authoring page:

1. Make the radio-location correction and let the waiting interval pass. Inspect the request payload for “lighting desk.”
2. Delay the response. Pending work should remain visible until the operation settles.
3. Force a failure through your test service. Keep the edited text available and show a failure or unsaved state; do not show a successful save.
4. Restore the service and verify that the current correction reaches the intended record. Leave and reopen that record to check the stored wording.

Record switching needs its own policy. A request started for rehearsal A must retain A's identity even if the user opens rehearsal B before it finishes. Bind the save operation to the record being edited, and resolve unsaved changes before destroying that editor.

Keep recovery separate from persistence

The TinyMCE browser recovery guide addresses local recovery drafts. CKEditor Autosave's server callback is a different boundary: a recovered or visible document still needs a successful application save. The CKEditor document editor guide covers layout and manual data capture.

For the rehearsal note, finish by reopening the saved record and reading the lighting-desk instruction. Keep the unsaved correction available until that server copy has been confirmed.