Editor Overview
Understand the editor role inside Anydocs and how the canonical content model relates to the upstream editor engine.
Anydocs uses Yoopta as the Studio editing engine, but saved page content is canonical `DocContentV1`. The editor only exposes the subset needed for structured documentation. Its job is to help you write docs, not to build marketing pages or low-code layouts. When reading upstream Yoopta material, treat it as editor background rather than the product contract.
What it handles inside Anydocs
Yoopta is the page-body editing engine inside Studio. In the central editor you use it to write paragraphs, headings, lists, code, tables, images, callouts, links, and Mermaid diagrams, while the saved source is normalized into canonical content blocks. Page title, slug, description, tags, and status are managed as page metadata outside the body editor itself.
The real starting workflow
When an empty page enters edit mode, the editor starts with a paragraph block. You can type directly or use `/` to open the block menu and insert the block you need. Block order can be adjusted with the editor drag handle. For most docs pages, start with paragraphs and H2/H3 headings first, then add code, tables, callouts, and images where needed.
The actual capability boundary
Anydocs currently exposes document-oriented blocks, not layout containers. The source of truth for supported content is this manual plus `project_open.authoring.contentFormat`, `allowedBlockTypes`, and `allowedMarks`. Even if upstream Yoopta has more plugins, you should not assume they are available in Anydocs.
How it affects the reader
Canonical page content is what the reader, TOC extraction, plain-text exports, and machine-readable outputs consume. So body structure is not only for editing convenience. It changes reader navigation, reading rhythm, and AI consumption quality. For example, heading level 2 and 3 blocks drive page TOC extraction, while inline code and standalone code blocks render differently in the reader.