Flare Flare PHP PHP JavaScript JavaScript Protocol Protocol

Introduction

View as Markdown

If you haven't turned on tracing yet, start with turn on tracing in the quick start. This page covers the Svelte-specific half: naming navigation spans after your SvelteKit routes. You can stop after the error reporting steps in the quick start and come back to this later. It isn't required to get errors into Flare.

On its own, @flareapp/js already traces page loads, client side navigations, and the fetch/XMLHttpRequest calls your page makes. This includes plain Svelte, without SvelteKit: the base client watches history.pushState, history.replaceState, and popstate itself, so a browser_navigation span opens whenever the path changes, no framework code required. What plain Svelte doesn't have is a router for Flare to read a route pattern from, so that span only knows the raw path, for example /products/482.

@flareapp/sveltekit adds the route pattern, through traceSvelteKitRouter(). This is SvelteKit only: plain Svelte has no router integration, so its navigation spans keep the raw path name described above.

Setting up the router integration

Call traceSvelteKitRouter() once, from src/hooks.client.ts:

// src/hooks.client.ts
import { traceSvelteKitRouter } from '@flareapp/sveltekit/client';

traceSvelteKitRouter();

Unlike a router integration in other frameworks, traceSvelteKitRouter() takes no arguments. It reads SvelteKit's own reactive navigation state directly, through $app/state's page and navigating, so there is no router instance to pass it.

It also replaces the base client's own History-based navigation detection, so a navigation is only ever traced once, not twice.

What the router integration adds

Without traceSvelteKitRouter(), a browser_navigation span only knows the path it navigated to, for example /products/482. With it registered, the span also contains SvelteKit's own route ID, taken from page.route.id verbatim, for example /products/[id], so every navigation to a product page groups together on the Pages table instead of becoming one entry for every product. When you open a single trace, you still see the path. Flare uses the route ID to group pages, not to name the span. The browser_pageload span for the very first load gets the same route ID. See the screenshot on the quick start for what a navigation span looks like in a trace.

What doesn't open a navigation span

traceSvelteKitRouter() follows SvelteKit's own navigation lifecycle, so a few things that change the URL don't open a browser_navigation span:

  • Shallow routing, pushState() or replaceState() imported from $app/navigation, since SvelteKit treats those as history updates, not page navigations.
  • A hash-only change to the URL.
  • A navigation a beforeNavigate guard in your app cancelled.
  • A navigation to a route SvelteKit itself doesn't own, since that unloads the document; the next browser_pageload span covers it instead.

Stopping the router integration

traceSvelteKitRouter() returns a stop function:

const stopTracingNavigations = traceSvelteKitRouter();

// Later, for example when tearing down the client in a test:
stopTracingNavigations();

Calling it stops opening navigation spans from SvelteKit's router state. You only need this if you tear down or reinitialize the client while your app keeps running, for example in a test.

Read more

Sourcemaps Introduction

On this page