Fetching content for Visual Editing

This article provides a high-level overview of how content fetching works with Visual Editing and the key concepts to understand when implementing it in your project.

If you are looking to just get started with Visual Editing in a project, you might want to explore the step-by-step guides. You can always come back to this article if you want to understand the mechanics more deeply.

Explore the following guides and courses:

Visual Editing enables content editors to use the Presentation tool to see and interact with their draft content directly in the context of your front-end application. At its core, this requires your application to:

• Fetch draft content when in preview mode
• Display this content in a way that supports real-time updates
• Enable interactive overlays for editor interactions

The way you implement these requirements can range from basic to advanced, depending on the requirements of your projects and the capabilities of your front end technology and hosting platform.

One of the key concepts to understand about Visual Editing is that it follows a progressive enhancement model.

The foundational layer of Visual Editing relies on server-side content fetching. This approach:

• Provides basic draft preview capabilities
• Reasonably fast refresh rates for preview
• Works with server-side rendering and framework-specific refresh APIs
• Requires minimal setup

With server-side fetching alone, editors can preview their draft content and get click-to-edit overlays. The preview experience will refresh up to seconds after edits and some advanced features in the Presentation tool won't work. Some frameworks and hosting platforms support server-rendering updates to a route programmatically, thus

Especially for existing projects, this can be the best way to get started with Visual Editing.

Basic preview requires the following:

• Server-side rendering and route and/or component-based data loading
• A server-side token with read permissions
• A way to pass the toggle for authenticated and enabled preview mode to the server

Building on the server-side foundation, Loaders use framework-specific features to enhance the Visual Editing experience:

• Provides advanced preview capabilities
• Sub-second refresh rates for previews
• Works with both server-side and client-side rendering
• Might require some more setup depending on framework constraints

In frameworks like Next.js, you can implement this without too much overhead with the next-sanity toolkit.

For Loaders to work with Visual Editing, there are a couple of requirements to how your front end application:

• A framework that supports client-side rehydration, like React, Vue, or Svelte
• A framework that has a built-in draft/preview mode, like Next.js or Nuxt

While static site generators can make it simple to build websites, they are not well-suited for providing a Visual Editing experience for content teams. Static site generators pre-render pages at build time, meaning any content changes require a full or partial site rebuild. This usually doesn't scale well as the site grows and by the nature of being static can't provide the real-time editing experience that Visual Editing offer.

However, some frameworks, like Astro, also support server-side rendering. Suppose you wish to use static site generation for your production builds. In that case, a strategy can be to set up a secondary deployment for previews that uses the server-side rendering approach.

To provide the best Visual Editing experience for your content teams, we recommend using a framework that supports server-side rendering and client-side hydration, such as Next.js, Remix, Nuxt.js, or SvelteKit. These frameworks allow you to leverage the full power of Loaders, including real-time updates and interactive editing overlays.