Skip to content

SWR recipes

Use shared subscriptions in a React app with SWR.

Open recipe

HTTP polling · Vite · React

Start with an existing Vite · React app. Keep its renderer, routes and plugins. These files add one live view; Spinetab does not create your API.

Your endpoint supplies complete { "open": 12 } values: JSON from GET /api/queue, read every five seconds by default.

The examples use same-origin URLs and declare anonymous: true: no token is supplied, although cookies still flow. For a separate API origin, use its URL and configure CORS or your application's proxy. For private data, add credentials and user scopes; never put a secret in these files.

Terminal window
pnpm add spinetab swr@^2.5.1

Keep your framework's existing dependencies. See compatible versions if upgrading an older app.

Merge this addition into your configuration; preserve existing plugins and options. Restart the dev server afterwards. The plugin bundles the worker and discovers the adapters imported below.

vite.config.ts
import react from "@vitejs/plugin-react";
import { spinetab } from "spinetab/vite";
import { defineConfig } from "vite";
export default defineConfig({ plugins: [react(), spinetab()] });

Save these files together in src/recipe/.

SWR uses its default cache. The constant queue key always returns the same source; if the endpoint varies, derive it from that key. With SWR 2.5.1 and React 19.3, avoid nesting a custom cache provider inside StrictMode; see the upstream restriction.

reconcile: "latest" fits this full-state contract: the next complete event restores the displayed value after a gap. Use a refresh/merge policy for deltas or partial GraphQL results. Reconnecting alone does not reconstruct missed state.

src/recipe/live.ts
import { createSpinetab } from "spinetab";
export const spinetab = createSpinetab({ anonymous: true });
src/recipe/queue-types.ts
export type Queue = { open: number };
export type QueueView = { open?: number; problem?: string };
src/recipe/source.ts
import { polling } from "spinetab/polling";
import type { Queue, QueueView } from "./queue-types";
export const queueSource = polling<Queue>("/api/queue");
export const selectQueue = (queue: Queue): QueueView => queue;
src/recipe/Recipe.tsx
import { swrSubscription } from "spinetab/swr";
import useSWRSubscription from "swr/subscription";
import { spinetab } from "./live";
import { queueSource, selectQueue } from "./source";
const subscribe = swrSubscription(spinetab, (_key: "queue") => queueSource, {
map: selectQueue,
reconcile: "latest",
});
export default function Recipe() {
const { data, error } = useSWRSubscription("queue", subscribe);
if (error || data?.problem)
return <p role="alert">{error?.message ?? data?.problem}</p>;
if (data?.open === undefined) return <p role="status">Loading queue…</p>;
return (
<p>
<output>{data.open}</output> open
</p>
);
}
src/App.tsx
import Recipe from "./recipe/Recipe";
export default function App() {
return <Recipe />;
}

Your existing entry point mounts App as usual. Keep its renderer plugin; no additional application provider is required beyond those shown.

Open the page in two tabs of the same browser profile. Both should show advancing queue values. Matching subscriptions share upstream work when SharedWorker is available; fallback runs independently in each tab. Remove one view and the other should keep updating. Removing the last view releases its subscription; connection closure can follow the adapter's idle delay.

API options and advanced recovery · Authentication