Storyblok rendered with SvelteKit, can I still use Croct without an official SDK?
hey all. Our Storyblok frontend is SvelteKit and I noticed the Croct SDK list covers React, Next.js, Vue, Nuxt and so on, but nothing for Svelte. Before I write this off, I hacked together a quick spike with the plain JavaScript SDK in a client-side load function and it seems to work?
What I want to sanity check: is the JS SDK or the raw HTTP API the intended base for stacks without a dedicated SDK, and what do I actually give up compared to the framework SDKs? Mostly worried about SSR since SvelteKit renders on the server by default and I dont want content popping in after load.
2 answers
Your spike is on the right track, and both paths you mention are supported.
For stacks without a dedicated SDK, the recommended base on the client is @croct/plug, the framework-agnostic JavaScript SDK. The pattern is:
import croct from '@croct/plug';
croct.plug({appId: 'YOUR_APP_ID'});
const {content} = await croct.fetch('home-hero') .catch(() => ({content: defaultHeroContent}));The catch keeps your Storyblok content as the fallback if the fetch fails, which matches the overlay model: the block content is always the default.
For server-side rendering, use the HTTP Content API from your SvelteKit server load functions instead. POST to the content endpoint with the slot ID and a context object; note that context.page.url is required. Resolving content on the server means the page arrives already personalized, with no client-side swap.
What you give up versus the framework SDKs is mostly convenience: provider wiring, hooks or components, and typed helpers. The underlying capabilities are the same. A practical SvelteKit split is HTTP API in server load functions for content, plus @croct/plug in the browser for event tracking.
Running exactly this in production, SvelteKit + Storyblok. One tip from experience: put the HTTP API call in a small wrapper in hooks.server.ts or a shared lib so every load function gets the same timeout and fallback behavior. And keep the fallback content close to the Storyblok response shape, then your Svelte components never need to know whether the content came from Croct or straight from Storyblok.
The shared wrapper idea is nice, stealing that. Moved my spike to a server load function and the popping is gone.