Core concepts

Regions & the schema

The compiler walks your JSX and identifies regions: text, images, links, .map() collections, and sections (<section> / <article> / @cms-section). Each gets a stable id derived from the component name plus its structural path (e.g. hero.section0-h11). These ids are written to cms-schema.json and injected as data-cms-id attributes — the schema and the DOM always agree. Sections are hide targets for whole page blocks; nested fields stay editable when the section is visible.

Override model

Your code provides defaults. The CMS stores overrides keyed by region id:

{
  "hero.section0-h11": { "value": { "en": "New headline" } },
  "features.section0-div2-collection": { "order": ["b", "a", "c"], "removed": ["c"] }
}

Because overrides are a separate layer, you get:

• Diff vs original (compare overrides to the published baseline)
• Revert (drop a region's override → fall back to code)
• Versioned rollback (each publish is an immutable snapshot)

In-place application

At runtime, CmsRuntime patches overrides onto the elements the compiler tagged — it sets textContent, swaps img.src, toggles display, and reorders collection items. No wrapper components, so your styles never break.

The overlay editor

In edit mode, NexusEditor renders inside a shadow root (full style isolation) and builds measured hit-targets over each region. That solves the classic z-index dead-zone: an image behind text still gets a clickable target.

Backends

The runtime talks to a StorageAdapter. The MVP ships:

• MemoryStorageAdapter — for demos and tests.
• HttpStorageAdapter — talks to the Filament/Laravel REST API.

Swapping the store later is just a new adapter.