Live Preview

[titouan-pellerin]

Description

I noticed your upcoming update for the live preview and was wondering—why fetch the data again using an SSR version of the site instead of just updating the DOM by passing the data directly to the iframe? I’m guessing it’s because mapping all Storyblok fields to specific DOM elements is tricky. It would be so convenient if the Visual Editor could simply load the static version of the site, rather than relying on a dedicated SSR endpoint.

Suggested solution or improvement

A potential improvement could involve enabling the Visual Editor to load a static version of the site and dynamically update the DOM using bridge events for hydration. This approach would remove the dependency on an SSR-specific endpoint, streamline the process, and make better use of existing static assets while reducing overhead.

Additional context

No response

Validations

• Follow our Code of Conduct

[titouan-pellerin]

Contentful CMS preview relies on a similar approach, where a static version of the site is loaded, and the DOM is dynamically updated using iframe events.

https://github.com/contentful/live-preview

[dipankarmaikap]

Hey @titouan-pellerin
Thank you for the feedback!

Astro ships with no client-side JavaScript by default, which makes live previews more challenging compared to reactive frameworks like React, Vue, or Svelte. These frameworks support DOM updates through hydration, but Astro components can’t be rendered on the client side.

Our current approach is to render the full page on an SSR endpoint and then manipulate the DOM. While this works for now, we’re always exploring improvements. Astro’s experimental container API could enable a solution like the one you suggested in the future, though it’s currently server-side.

We appreciate your suggestion and will keep it in mind as we improve the SDK!

Best regards,

[titouan-pellerin]

Hey @dipankarmaikap,

I know what you mean, although it's doable with vanilla javascript with data-attribute to map real dom elements to storyblok fields. I agree that in some cases this could be difficult to manage, for complex components like repeaters for example.