Live Previews for content editing

[louisescher]

Body

Summary

A feature that a lot of CMSs provide for their users is a live preview of the content they're editing on the page that will eventually display the content. StudioCMS could massively benefit from this, and there are multiple ways of implementing such a system in a way for plugins to hook into.

Background & Motivation

Content Management Systems, for example Payload, allow you to edit the content on a page while previewing it, giving you a better feeling for how the content will end up looking on the eventual webpage. The disconnect between rich text editor and web page can often be quite large, not only in regards to fonts and text size but also in regards to how images are displayed. Being able to view the content as you're editing it would be an incredible improvement to the user experience.

Goals

• Implementing a live preview for the built-in StudioCMS editors.
• Adding an SDK or similar to allow plugin authors to implement live previews for their own types of editors.

Example

I have created an example of a very simple yet effective method using iframes. This system uses the little-known XPath API to find text that contains a comment on a page and then communicates changes in that text between the iframe and the editor by posting messages between the windows.

https://github.com/louisescher/iframe-poc

Alternatives

A member of the community has pointed out two alternatives to the XPath approach:

• @vercel/stega: Hiding information within the text itself using stegonography
• Sanity's Content Source Maps

[Adammatthiesen]

/consensus

[Adammatthiesen]

My only concern is ensuring it works across different rendering plugins if its going to be part of the core rendering pipeline. as long as you can ensure this, then i have no issues here.

[louisescher]

I think I'll manage that!

[dreyfus92]

I like this proposal, a few things i'm wondering:

• How will the live preview handle large pages or complex content structures?
• Real-time vs debounced updates (to avoid excessive re-rendering)
• What will happen when the preview fails to load or update?
• WiIl this preview be responsive or web only?
• Will it have content validation e.g. detection of broken links, missing alt text, etc.?
• Accessibility preview (screen reader sim)?

[louisescher]

How will the live preview handle large pages or complex content structures?

For one, XPath is highly performant. Since we're loading everything in an iframe, the browser can take care of loading the page, we just replace some content. Shouldn't be too bad.

Real-time vs debounced updates (to avoid excessive re-rendering)

Probably going to do a debounce of 300ms to 500ms, didn't put it in the POC because I couldn't be bothered

What will happen when the preview fails to load or update?

First of all, it shouldn't. If it does, we display an error message instead of the preview telling the user to reload the page, retry loading the preview or submitting a bug report.

WiIl this preview be responsive or web only?

Unsure what you mean? I can make the preview resizable if that is what you refer to.

Will it have content validation e.g. detection of broken links, missing alt text, etc.?

I'd say that's a non-goal.

Accessibility preview (screen reader sim)?

Interesting. But for now, a non-goal.

[dreyfus92]

Everything sounds good, we just gotta make sure to establish all the goals and reqs for this 😁