SPA editor overview
Purpose: Understand how React/Angular SPAs integrate with AEM authoring, and when to choose SPA vs server-rendered.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| React engineers | The "can I just write React?" answer |
| Tech leads | Architecture choice |
The idea
The SPA editor pattern lets a React app render AEM content while remaining author-editable: the app consumes the page's .model.json, maps resourceTypes to React components, and the author's editor overlays editing UI onto the running app.
AEM page model (.model.json)
│
▼
@adobe/aem-react-editable-components
MapTo('phi/components/plancard')(PlanCard) ← resourceType → React component
│
▼
React renders; author edits in place; edits persist to JCR; model refreshesThe trade, honestly
| Server-rendered (HTL) | SPA editor | |
|---|---|---|
| Frontend DX | HTL + clientlibs | Full React toolchain |
| Rendering | Cached HTML, fast TTFB | JS boot cost; SSR possible but complex |
| Authoring fidelity | Full | Good, with discipline (editable containers, model sync) |
| Component cost | HTL+dialog+model | React component + dialog + model + MapTo |
| Caching | Simple (pages) | Model JSON + app shell caching design |
| Team fit | Mixed teams | Strong JS teams committed to the pattern |
Guidance
- Content sites (like the PHI plan pages) are usually better served by HTL + progressive client-side JS — the caching story alone decides it.
- Choose SPA editor when the experience is genuinely app-like (calculators, portals) AND authors must compose it.
- Never mix per-page: pick per site/section, or embed small React widgets inside HTL pages (a lightweight, often better, third option — mount a React component in a component's DOM node, feed it
.model.json).