SSR support

The provider is safe to render on the server. It creates the tracker during render but only calls init() in an effect, which never runs on the server. Nothing is sent until the page hydrates.

Next.js App RouterCopy Anchor Link

Recent releases of @supapulse/react include a 'use client' directive. Older ones don't, and importing SupapulseProvider straight into a server component fails. Wrapping the provider in your own client component works with every version:

'use client';

import { SupapulseProvider } from '@supapulse/react';
import type { ReactNode } from 'react';

const config = { apiToken: process.env.NEXT_PUBLIC_SUPAPULSE_TOKEN! };

export function Analytics({ children }: { children: ReactNode }) {
  return <SupapulseProvider config={config}>{children}</SupapulseProvider>;
}

Use <Analytics> in app/layout.tsx. Components that call the hooks must also be client components.

Next.js Pages RouterCopy Anchor Link

pages/_app.tsx already runs on the client after hydration; use the provider there directly. See installation.

RemixCopy Anchor Link

Put the provider in app/root.tsx around <Outlet />. Remix navigates with the History API, so route changes are tracked.

GatsbyCopy Anchor Link

Use wrapRootElement in gatsby-browser.tsx only. There's nothing to do in gatsby-ssr.tsx, since the tracker can't run on the server anyway.

GotchasCopy Anchor Link

• Don't call useSupapulse().event() during render. The tracker isn't initialized on the server or on the first client render, so the call is dropped.
• No hydration mismatches. The provider renders only its children, so server and client markup match.
• Server-side events. The browser tracker can't run on the server. For revenue, use the HTTP API with the secret token.