Consider a fictional maintenance procedure with a short “Replacement parts” section. The author opens it while checking a part number. That temporary editing action should not necessarily change how every reader first sees the procedure. A different document may deliberately start with a long safety explanation expanded, making persistence a conscious document choice.
Register the complete node family
For an existing Tiptap editor with compatible packages, add these extensions alongside its normal document, text, paragraph, and other required nodes:
import {
Details, DetailsSummary, DetailsContent
} from '@tiptap/extension-details';
const procedureDetails = [
Details.configure({ persist: false }),
DetailsSummary,
DetailsContent
];
Include the entries from procedureDetails in the editor's existing extension list. Register each node once. Retain the normal application styles and any Details styling required by the editor's integration. This fragment supplies the schema family; it does not initialize an editor or create a saved procedure.
The summary and content nodes give the editor a structured representation of the disclosure. Pasting arbitrary DOM into the editable surface bypasses that model. Load supported content through the application's established Tiptap import route and inspect the resulting document.
Separate navigation from an authoring decision
With persist: false, opening a section is local interface state rather than an open-state change saved in the document. If authors are intentionally selecting the document's expanded state, configure persist: true instead:
const detailsWithSavedOpenState = Details.configure({
persist: true,
openClassName: 'is-open'
});
Use this in place of the previous configured Details entry. Do not add a second Details extension. openClassName names a CSS hook for toggled content; the class itself is not proof of what the application saved.
Check the representation actually stored by the application. If it saves JSON, inspect the Details node and its state before and after toggling. If it exports HTML, inspect that output too. A correct editor model does not guarantee that a custom server renderer or sanitizer preserves the same attributes.
The plain HTML accordion guide covers native reader markup and disclosure behavior. This editor configuration adds a separate decision: whether the author's toggles modify document data.
Wrap and unwrap through editor commands
The documented commands operate on the current editor selection:
editor.chain().focus().setDetails().run();
// For a selection inside a Details node:
editor.chain().focus().unsetDetails().run();
Use these as alternative actions, not sequential initialization steps. A toolbar's “Create section” control should wrap the intended content, while “Remove section” should unwrap an existing node. Preserve the author's selection and inspect command availability for the current schema and selection.
Write a summary that identifies what is hidden: “Replacement parts for the intake filter” is more useful than “More.” Keep essential instructions visible in the procedure. A reader should not need to discover a collapsed part list to learn that the machine must be isolated before work begins.
Verify a round trip with both policies
Create a disposable procedure containing the part number IF-42 inside one Details section. With persistence disabled, open and close it, capture the document, reload it through the normal application route, and inspect whether toggling changed stored data. Repeat with persistence enabled and confirm that the stored state and the reader's initial view match the chosen policy.
Then edit the part number, save, and reopen the record. Confirm the new number survives regardless of the chosen open-state policy. Finally unwrap the section in a disposable copy and verify that its summary and body are handled as intended. Finish with the actual recipient view: the correct replacement part must be discoverable, and critical safety wording must remain visible before the reader opens anything.