Live Preview and Visual Builder are where many developers either become confident with Contentstack or become deeply confused by it. The concepts are powerful, but only if you understand the runtime model clearly.

What you'll learn

What Live Preview actually does
Why preview tokens exist and when they are used
What editable tags and CSLP-style bindings are for
What Visual Builder expects from your frontend
How Veda centralizes preview behavior
Which parts of preview are platform concepts versus project-specific design choices

What Live Preview is doing

Contentstack concept: Live Preview lets editors see draft changes reflected in a running site experience before those changes are published.

That sounds simple, but it involves several moving parts:

the Contentstack editing interface
your running website
preview-aware APIs and tokens

The key idea is this: preview mode is not just "reload the same data." It is a dedicated draft-aware content delivery path.

Why preview tokens exist

Contentstack concept: A preview token allows the app to read draft content safely for preview workflows.

This is different from:

a delivery token, which is for published content
a management token, which is for administrative write access

That separation matters because preview is still content delivery, but it is draft-aware content delivery.

Editable tags and field bindings

Contentstack concept: Preview experiences often need the rendered page to retain enough field-level information for the CMS to understand which visual element maps to which content field.

In Veda, that shows up as editable tag handling and preview-oriented bindings on rendered content.

The result is not just "you can see draft data." It is "the editing interface can connect visible elements back to their source fields."

That is what makes click-to-edit and builder workflows feel integrated instead of bolted on.

Code example: where the editable tags come from

This is the important preview detail in the current Veda fetchers:

if (isPreview) {
  contentstack.Utils.addEditableTags(entry as EmbeddedItem, "page", true);
}if (isPreview) {
  contentstack.Utils.addEditableTags(entry as EmbeddedItem, "page", true);
}

That one line explains why the returned object in preview mode is richer than in normal delivery mode. The content itself is still the content, but the object is augmented with field-level metadata so the preview UI can understand it.

What Visual Builder expects

Contentstack concept: Visual Builder works best when your frontend renders structured content in a way the CMS can target reliably.

In practice, that usually means:

modular content is rendered predictably
field-level bindings are preserved
empty modular areas still have a recognizable editable container
preview updates can trigger the right refresh behavior

If your frontend strips away too much structure, Visual Builder gets weaker. If your frontend preserves the right markers, the editing experience becomes much better.

How Veda handles preview centrally

Veda implementation: The Veda repo uses a dedicated preview component that:

initializes the preview runtime
subscribes to content change events
re-fetches the relevant entry type based on the current route
renders the appropriate page-level component

This is a very good design choice because it keeps preview logic out of the main page components as much as possible.

It also means the project can support preview across multiple content types without duplicating the same subscription logic everywhere.

DiagramMermaid

This diagram is the runtime model in one glance:

editors do not push HTML into the app
the app does not receive the whole page as an event payload
the event tells the app to refetch
the app then re-renders from fresh preview data

Code example: the preview event loop

This excerpt from components/Pages/Preview.tsx shows the heart of the runtime:

const getContent = useCallback(async () => {
  const data = await getPreviewData(type, path);
  setContent(data);
}, [path, type]);

useEffect(() => {
  initLivePreview();
  ContentstackLivePreview.onEntryChange(getContent);
}, [path, getContent]);const getContent = useCallback(async () => {
  const data = await getPreviewData(type, path);
  setContent(data);
}, [path, type]);

useEffect(() => {
  initLivePreview();
  ContentstackLivePreview.onEntryChange(getContent);
}, [path, getContent]);

What is happening here:

the component decides which content to refetch based on type and path
Live Preview is initialized once the client component is mounted
every editor change triggers a new fetch
the local React state is replaced with the latest draft-aware content

That is why preview feels live without turning every route into a totally separate preview implementation.

Why Veda's preview model is worth learning

Veda implementation: Veda is broad enough that preview cannot be treated like a one-page demo trick.

Preview needs to work across:

general pages
categories
product lines
products

By centralizing the behavior, the repo teaches a reusable lesson: treat preview as a runtime mode with its own orchestration layer.

What the preview-enriched payload feels like

Contentstack concept: In preview mode, the frontend still receives recognizable content fields such as title, description, components, or product_line. The difference is that the object can also carry $ mappings for editor targeting.

Conceptually, that means you can think of a preview page object like this:

{
  "title": "The Revival Collection",
  "components": [
    {
      "hero": { "title": "The Revival Collection" }
    }
  ],
  "$": {
    "title": {
      "data-cslp": "page.title"
    },
    "components": {
      "data-cslp": "page.components"
    }
  }
}{
  "title": "The Revival Collection",
  "components": [
    {
      "hero": { "title": "The Revival Collection" }
    }
  ],
  "$": {
    "title": {
      "data-cslp": "page.title"
    },
    "components": {
      "data-cslp": "page.components"
    }
  }
}

The exact binding values are generated by the preview utility layer, but the important idea is simple:

normal fields are for your UI
$ fields are for the editing system

What is generic Contentstack behavior versus Veda-specific behavior

This distinction matters a lot.

Contentstack concept: These ideas are broadly portable:

preview uses draft-aware delivery
preview tokens differ from delivery tokens
editable bindings help the CMS target fields
visual editing benefits from predictable structured rendering

Veda implementation: These are Veda-specific choices:

the exact preview component structure
the set of supported content types
the route-to-fetcher mapping used during preview refreshes
the exact way preview mode is toggled in env vars

Learn the platform model first, then borrow the implementation pattern that fits your own project.

A reliable debugging order

Production note: If preview fails, do not start by debugging everything at once. Work in this order:

confirm published content fetch works
confirm preview token and preview config exist
confirm preview mode is actually enabled in the app
confirm editable bindings are present where expected
confirm change events lead to a re-fetch and re-render

That sequence saves a lot of time.

Key takeaways

Live Preview is a draft-aware content delivery workflow, not just "regular fetch plus refresh"
Preview tokens exist to support draft delivery safely without using write credentials
Editable tags and bindings help map rendered output back to source fields
Visual Builder depends on predictable structured rendering and preview-aware wrappers
Veda's dedicated preview wrapper is a strong pattern because it centralizes the editing runtime