Skip to main content
@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 with TrafficalProvider in a root layout:
Use an SDK key (traffical_sk_..., scopes sdk:read+sdk:write) in browser code — it is browser-safe.

Resolving parameters

Use useTraffical 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:
To customize the unit key, pass unitKeyFn inside config as well.

SvelteKit SSR

Fetch the bundle in a server load function and pass it through to the client to avoid a second fetch:
The server resolves with the bundle. The client picks up the same bundle via 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.
See SSR patterns for the full pattern, including per-page pre-resolution.

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.