Lifecycle and events
Own Editor in a component and subscribe to content, selection or transaction changes as needed.
A page normally creates one Editor until the user leaves. Input changes its state; application code observes events without recreating the instance.
Create, mount and exit
In Vue, create a view-backed Editor after onMounted and call destroy() on exit. Release application subscriptions and asynchronous tasks too.
See Vue integration for one complete component. A headless instance can be mounted later with mount(). unmount() keeps content; destroy() ends the instance.
beforeCreate and create fire synchronously during construction. Register onCreate({ editor }) through creation options and use its supplied instance. Subscribing to create after construction misses the event. mount fires when the primary View is ready, and unmount when released; mode changes also pass through these phases.
Choose an event
| Concern | Event | Typical use |
|---|---|---|
| Content changes | update | Mark unsaved changes |
| Selection changes | selectionUpdate | Refresh selection-related interface |
| Accepted transaction | transaction | Refresh toolbar state centrally |
| Focus changes | focus / blur | Focus appearance and interface visibility |
| Primary View mounted/released | mount / unmount | Bind and release resources owned by that View |
Subscribe only where needed. Moving the cursor is not a content edit and does not require serializing the document.
Keep the listener for cleanup
import type { QuireEditorUpdateEvent } from '@quirekit/core'
const onUpdate = ({ editor, previousState }: QuireEditorUpdateEvent) => {
if (!previousState.doc.eq(editor.state.doc)) dirty = true
}
editor.on('update', onUpdate)
// When the page exits:
editor.off('update', onUpdate)
dirty is application-owned unsaved state. setEditable() also emits update by default; compare documents to avoid treating read-only changes as edits. Content replacement with emitUpdate: false skips the event, so restoration establishes its baseline explicitly. Do not unconditionally call setContent() inside update, repeatedly replacing the user's content.
transaction carries the root transaction and appendedTransactions. Its editor.state includes accepted plugin appends. Looking only at the root's docChanged misses appended edits; treating every transaction as content worth saving also overcounts. See the complete event map.
Asynchronous results have a lifecycle too
When loading or saving finishes, verify the page and task are still current. Older results must not overwrite drafts or recreate an unmounted instance.
Classic product configuration updates differ from Core content update; see Classic configuration.