Agent setup: authorize Sight MCP and ask your agent to call get_tracking_setup. It configures this integration automatically.

#React Router

Sight analytics for React Router. Thin wrapper around @sightapp/analytics — same init/track API.

#Install

npm install @sightapp/react-router

@sightapp/analytics isn't published to npm yet — until it ships, point your lockfile at the local checkout instead:

npm install file:../sight-js

#Usage

Render once, near the root of your router:

import { BrowserRouter } from "react-router-dom";
import { SightAnalytics } from "@sightapp/react-router";

function App() {
  return (
    <BrowserRouter>
      <SightAnalytics apiKey="pk_your_project_api_key" />
      {/* your routes */}
    </BrowserRouter>
  );
}

Custom events, anywhere:

import { track } from "@sightapp/react-router";
track("signup");

#How SPA navigation is tracked

init() patches history.pushState and fires a pageview on every call. React Router's createBrowserHistory (used by <BrowserRouter> and createBrowserRouter/RouterProvider) is built directly on the native History API, so every client-side navigation already routes through pushState/replaceState — no separate useLocation-based tracking here, since that would double-count every navigation on top of the patch. This is well-documented React Router behavior for the standard browser setup, not an untested assumption.

Doesn't apply if you're using a non-browser history — createMemoryRouter (tests) or React Native (see @sightapp/react-native instead) don't have a window.history to patch.

#Build

npm run build       # tsup: emits dist/{index.js,index.cjs,index.d.ts}
npm run typecheck

Source repository