How Dollie Editor Works

Dollie Editor uses one structured contract from the first drag to the published page.

Your React components
    → Catalog
    → Editor and Copilot
    → PageConfig
    → Validation
    → Your storage
    → SectionRenderer

1. Register approved components

You register React components as Sections in a Catalog.

A Catalog gives each Section a stable id and describes its editable fields. It can also include Illustrations, Widgets, and complete Page Templates.

const productSource = {
    id: 'product',
    label: 'Product pages',
    prefix: 'product-',
    sections: [
        {
            id: 'hero',
            name: 'Product hero',
            category: 'hero',
            component: ProductHero,
            authorable: true,
        },
    ],
};

The stored id becomes product-hero. That id is a public contract: pages, templates, validation, and Copilot tools all use it.

2. Compose a page as data

A Page is a PageConfig: an ordered list of Section ids and their editable props.

{
  "_version": 1,
  "sections": [
    {
      "component": "product-hero",
      "props": {
        "headline": "Turn expertise into a course"
      }
    }
  ]
}

The editor changes this data. It does not generate a second page-component tree.

3. Edit through the shared catalog

The editor runtime receives:

• the Catalog used to resolve components;
• field definitions used by the inspector;
• optional renderers for icons, elements, and error boundaries;
• optional binding definitions for dynamic data.
• optional Page Templates for the current surface;
• an optional fixed-size presentation canvas.

The section library, canvas, layers panel, and props inspector all work from that runtime. Each section card identifies the Catalog Package and component Source behind it, so composed libraries remain easy to distinguish while browsing.

4. Validate every external proposal

Changes made through the editor already follow its contract. Definitions from outside the editor—AI proposals, imports, templates, or API clients—must pass validatePageConfig before they are applied or stored.

Validation rejects:

• unknown Section ids;
• malformed Section data;
• invalid props containers;
• invalid themes, borders, dividers, and additional class names;
• malformed Element references;
• Elements placed in incompatible Slots;
• unknown registered Elements.

For a single-section Copilot edit, use validateSectionConfig.

5. Store the document in your application

Dollie Editor does not choose your database or tenant model.

The SDK defines a TransportClient and a BuilderDocument. You can:

• start with the in-memory transport;
• use the Node file-store reference implementation;
• connect your own HTTP backend;
• use the Laravel adapter;
• post Page definitions through an existing Inertia controller.

The document can carry capabilities and a revision token for conflict detection.

6. Render the published page

Use the same Catalog to render the stored definition:

<SectionRenderer catalog={catalog} definition={page.definition} />

SectionRenderer resolves each Section id and passes the stored props to your component. The public page is therefore made from the same React components the editor preview used.

7. Add a Copilot without creating another model

A Copilot reads a compact description of the Catalog, looks up field details when needed, and proposes either:

• a complete Page for creation or remixing;
• one complete Section for a focused edit.

The proposal goes through the same validation gate before the editor user can apply it.

The Copilot does not need permission to generate arbitrary JSX. It composes with the product vocabulary you registered.

One contract, several interfaces

The visual editor, Copilot, templates, MCP tools, and published renderer are different interfaces over the same Page and Catalog contracts.

Keeping those contracts shared is what makes the system understandable and safe.

Next steps

• Learn the Page and Section model.
• Understand Catalogs and the Core Catalog.
• Review Guardrails and Validation.