Live preview -- real-time front-end updates during admin editing

[mvanhorn]

When editing content in the admin, there's no way to see changes reflected on the front-end in real-time. You have to save, switch to the browser, and refresh.

Payload CMS and Sanity both offer live preview where admin edits update the front-end instantly. Simeon Griggs noted this gap in his review: "What I'd also like to see is live preview on my front end. Unfortunately, I don't seem to get that either."

Proposed approach

1. Add an SSE endpoint at /_emdash/api/preview/events that streams draft content changes
2. The Astro integration subscribes to this endpoint in dev mode (and optionally in production for preview mode)
3. When a field changes in the admin, the handler emits an event with the updated content
4. The front-end re-renders the affected component without a full page reload

Why SSE over WebSockets

• Works with existing HTTP infrastructure (no upgrade needed)
• Simpler to implement on Cloudflare Workers
• One-directional (admin -> front-end) is sufficient for preview

Phased scope

• Phase 1: Dev mode only, full page content refresh on any field change
• Phase 2: Granular field-level updates, production preview mode with auth
• Phase 3: Split-pane preview in admin (iframe approach)

Phase 1 could serve as a proof of concept before investing in the full implementation. The visual editing toolbar already has front-end presence, so there's a natural integration point.

Happy to start with Phase 1 if the approach looks right. Open to different technical directions.

[nickgraynews]

Oh, this is cool! I didn't realize that EmDash is missing this. And I appreciate that Payload CMS has it (the other option that I am considering for my large stack of WordPress websites).

I'll share a link to this thread in the Discord to see if anyone else has ideas for how to implement it.

Otherwise - thank you @mvanhorn for taking a stab at it and getting started on Phase 1!!

[BenjaminPrice]

I think this is something that should 100% be added. The path suggested makes sense to me, as well.

[coreylight]

A reproducible EmDash 0.35.0 fixed-template workflow adds another acceptance case for live preview: a page composed from more than one CMS entry.

Our Astro page queries a routable pages/home entry plus three non-routable page_sections entries in fixed slots. Editing and saving the Home problem section creates a valid draft, but:

• the child entry has no Preview action because it has no independent public route;
• the normal homepage correctly continues to render published content;
• the signed parent Page preview also renders the published child section, so there is no supported way to review the section draft in its actual page context before publishing it.

I verified the behavior in the real admin, not only through API inspection: change the published child title, wait for Saved, open the signed parent preview, and both public and preview responses retain the old child title. Discarding the child draft restores the expected clean state.

This is distinct from a generic page builder: the Astro components and six allowable template slots are fixed in code. The missing piece is a preview context that can compose draft revisions from related or explicitly registered child entries while continuing to keep them out of unsigned public responses.

For the phased proposal here, I suggest including a multi-entry acceptance case and defining how draft visibility is scoped. A signed preview session might resolve draft revisions reachable from the parent reference graph, or allow the site to register the child queries that belong to the preview. Either approach needs to avoid exposing unrelated drafts and must remain no-store.

Related page-composition discussion: #337. This evidence comes from Astro 7.2.6 + EmDash 0.35.0 on the Cloudflare adapter with local D1/R2.