Skip to main content
Our docs redesign is live!
svelte.svg

Kickstart SvelteKit

•
5 min read
svelte

If you want a Contentstack example in SvelteKit that stays compact but still shows a server-aware preview flow, this kickstart is a strong one to inspect.

Like the Astro kickstart, the SvelteKit version is especially interesting because of how it handles preview state. It uses request-aware page loading and initializes Contentstack Live Preview in SSR mode, which makes it feel closer to the SSR-style kickstarts than to the pure client-refresh examples.

This page is a practical developer guide based on the repository itself, not a replacement for official docs. The goal is to show how the repo is structured and what patterns it is teaching.

What a kickstart is

A kickstart is the smallest useful project that connects a frontend framework to Contentstack. It is meant to keep the integration understandable by focusing on a few core concerns:

  • SDK setup
  • content querying
  • preview configuration
  • editable field bindings

That is why the SvelteKit kickstart is valuable. It gives you a working Contentstack baseline without hiding the important logic.

Why start with the SvelteKit kickstart

This kickstart is a good fit when you want to:

  • learn how Contentstack fits into a SvelteKit app
  • understand preview behavior that depends on request query parameters
  • start from a very small codebase
  • grow a server-aware SvelteKit site from a minimal example

It is a nice starting point if you want SvelteKit but still need a more structured preview story than a purely client-side refresh loop.

What you get out of the box

The current contentstack/kickstart-sveltekit repository includes:

  • SvelteKit
  • a shared Contentstack helper in src/lib
  • a page load function that reads preview query state
  • Live Preview initialized in SSR mode
  • Visual Builder editable field bindings
  • a seeded page content type with a sample homepage

That means the repo is teaching both the Contentstack fetch pattern and the preview flow at the same time.

How this specific kickstart works

1. src/lib/index.ts sets up the SDK and preview utility

This file owns the main integration work:

  • creates the Delivery SDK stack
  • maps region-aware delivery and preview endpoints
  • initializes Live Preview with ssr: true
  • exposes getPage(url, searchParams) for preview-aware queries

It also applies livePreviewQuery(...) when preview query params are present and adds editable tags before returning the page entry.

That makes it the best place to read first if you want the overall mental model quickly.

2. src/routes/+page.ts connects the request URL to the page query

The page load function reads live_preview, content_type_uid, and entry_uid from url.searchParams, then passes those into getPage("/").

That is the key SvelteKit pattern in this repo. The page data is not only “fetch content by URL.” It is also “apply preview query context if the request includes it.”

This is what makes the preview flow feel server-aware.

3. Browser-side initialization is kept small

Inside +page.ts, the app calls initLivePreview() only in the browser.

That means the browser still participates in the editing experience, but the actual draft-content lookup stays coordinated through the request data and the SDK query configuration.

4. src/routes/+page.svelte keeps rendering straightforward

The page component renders the familiar content structure:

  • title
  • description
  • hero image
  • rich text
  • modular blocks

It also spreads the editable field bindings directly onto the rendered elements, which keeps the Visual Builder integration very easy to see in the template.

The important preview nuance

This kickstart uses ssr: true for Live Preview.

That means the editing flow works like this:

  • Contentstack appends preview parameters to the URL
  • the preview iframe reloads
  • SvelteKit reads those parameters during page load
  • the page fetches the newest draft content again

So the repo is not just a Svelte example. It is a SvelteKit example built around a server-aware preview loop.

What you are really learning from this project

This repo is useful because it teaches a few good SvelteKit-shaped patterns:

  • keep the Contentstack setup in a shared library module
  • let the page load function own request-aware data fetching
  • bind editable fields directly in Svelte markup
  • use the preview query state as part of the fetch logic

That makes it a strong baseline if you want a SvelteKit app with a more structured preview experience.

When to choose this one

Choose the SvelteKit kickstart when:

  • you want a compact SvelteKit + Contentstack example
  • you want preview behavior driven by request query params
  • you prefer an SSR-style editing loop over a purely client-side refresh callback
  • you want a small project that still feels close to a real SvelteKit app structure

If you want the most straightforward client-refresh model, React or Angular are closer to that in this set.

Fastest way to try it

The shortest path is:

  1. Clone the repo.
  2. Seed or reuse the kickstart stack.
  3. Create a delivery token with preview enabled.
  4. Add the Contentstack values to .env.
  5. Enable Live Preview for the same environment.
  6. Run npm install and npm run dev.

One detail to keep in mind: the repo expects the local preview URL to be http://localhost:5173/, so that is the URL you want to use in the Contentstack environment settings.

A good next step after the first run

After the homepage works, the best follow-up is adding another route and reusing the same +page.ts pattern. That is where the repo becomes especially helpful: it gives you a very clear way to keep preview-aware data loading close to the route that needs it.