@traffical/svelte integrates Traffical with Svelte’s runes and SvelteKit’s data-loading system. It wraps @traffical/js-client, so everything the browser client supports works here too.
Requires Svelte 5 (uses runes).
Installation
Setup
Wrap your app withTrafficalProvider in a root layout:
traffical_sk_..., scopes sdk:read+sdk:write) in browser code — it is browser-safe.
Resolving parameters
UseuseTraffical in any component:
params is reactive via runes — Svelte automatically re-renders when the bundle refreshes or context changes.
Setting context
TrafficalProvider takes exactly two props: config and children. Context is supplied through config.contextFn — a function called on each resolution, so hooks re-resolve when the values it returns change:
unitKeyFn inside config as well.
SvelteKit SSR
Fetch the bundle in a serverload function and pass it through to the client to avoid a second fetch:
initialBundle and hydrates without a second fetch. No flash of original content.
The server-fetched bundle goes through
initialBundle — that is what marks the provider ready during SSR. localConfig is the separate build-time/offline fallback bundle. Without an initialBundle (client-only usage), params start at your defaults and update as soon as the first background fetch lands.Anonymous users and identify
The Svelte SDK uses the browser client’s stable-ID handling. When the user logs in:
useTrafficalClient() returns { client, ready, error } — destructure client (it can be null until the provider initializes):
Next steps
SSR patterns
Avoiding FOOC with SvelteKit and Next.js.
Canonical experiments
Patterns for web UI and SSR tests.