Integration React React Router 7 Framework
PostHogOfficialCreated by PostHog
- Skill
- Tool integration
- Data and AI
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a comprehensive workflow for adding PostHog analytics, session replay, feature flags, and error tracking to React Router v7 Framework applications. It emphasizes a hybrid approach, utilizing client-side initialization for user identification and event tracking, while requiring server-side middleware to maintain session correlation and capture critical business operations. The skill includes strict guidelines on React best practices, such as avoiding useEffect for event handling, and provides a clear, multi-step process for implementation.
What it does
- Guides the integration of PostHog into React Router v7 Framework mode projects.
- Provides a structured 4-step workflow for setup, editing, revision, and conclusion.
- Defines patterns for server-side and client-side event tracking.
- Establishes best practices for user identification and error tracking.
- Includes reference examples for middleware and component-level implementation.
- Enforces the use of environment variables for secure configuration.
When to use it
- When you need to add product analytics to a React Router v7 Framework application.
- When you need to implement session replay and feature flags in a React Router environment.
- When you need to track critical business events on both the client and server sides.
- When you want to ensure your analytics implementation follows established React and PostHog best practices.
Advantages
- Ensures consistent event tracking across client and server boundaries.
- Promotes clean code by discouraging misuse of useEffect.
- Provides a clear, repeatable process for integration.
- Maintains user session correlation using standard header-based tracing.
Usage examples
- “How do I initialize PostHog in my React Router v7 application?”
- The skill directs you to configure the PostHogProvider in entry.client.tsx using your project token and host from environment variables.
- “Should I track user login on the server or client?”
- The skill specifies that user identification must occur on the client-side, while server-side events should be used for critical business operations like authentication endpoints.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/posthog/integration-react-react-router-7-framework/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip integration-react-react-router-7-framework.zip -d .agents/skills
Documentation by PostHog
PostHog integration for React Router v7 - Framework mode
This skill helps you add PostHog analytics to React Router v7 - Framework mode applications.
Workflow
Follow these steps in order to complete the integration:
basic-integration-1.0-begin.md- PostHog Setup - Begin ← Start herebasic-integration-1.1-edit.md- PostHog Setup - Editbasic-integration-1.2-revise.md- PostHog Setup - Revisebasic-integration-1.3-conclude.md- PostHog Setup - Conclusion
Reference files
references/EXAMPLE.md- React Router v7 - Framework mode example project codereferences/react-router-v7-framework-mode.md- React router v7 framework mode (remix v3) - docsreferences/identify-users.md- Identify users - docsreferences/basic-integration-1.0-begin.md- PostHog setup - beginreferences/basic-integration-1.1-edit.md- PostHog setup - editreferences/basic-integration-1.2-revise.md- PostHog setup - revisereferences/basic-integration-1.3-conclude.md- PostHog setup - conclusion
The example project shows the target implementation pattern. Consult the documentation for API details.
Key principles
Environment variables: Always use environment variables for PostHog keys. Never hardcode them.
Minimal changes: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.
Match the example: Your implementation should follow the example project's patterns as closely as possible.
Framework guidelines
For feature flags, use useFeatureFlagEnabled() or useFeatureFlagPayload() hooks - they handle loading states and external sync automatically
Add analytics capture in event handlers where user actions occur, NOT in useEffect reacting to state changes
Do NOT use useEffect for data transformation - calculate derived values during render instead
Do NOT use useEffect to respond to user events - put that logic in the event handler itself
Do NOT use useEffect to chain state updates - calculate all related updates together in the event handler
Do NOT use useEffect to notify parent components - call the parent callback alongside setState in the event handler
To reset component state when a prop changes, pass the prop as the component's key instead of using useEffect
useEffect is ONLY for synchronizing with external systems (non-React widgets, browser APIs, network subscriptions)
Identifying users
Identify users during login and signup events. Refer to the example code and documentation for the correct identify pattern for this framework. If both frontend and backend code exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to maintain correlation.
Error tracking
Add PostHog error tracking to relevant files, particularly around critical user flows and API boundaries.
Files
- ATTRIBUTION.mdAdded by AutoGineer1.0 KiB
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md3.0 KiB
- references/EXAMPLE.md32.2 KiB
- references/basic-integration-1.0-begin.md2.1 KiB
- references/basic-integration-1.1-edit.md2.5 KiB
- references/basic-integration-1.2-revise.md937 B
- references/basic-integration-1.3-conclude.md1.6 KiB
- references/identify-users.md8.1 KiB
- references/react-router-v7-framework-mode.md14.9 KiB
references/identify-users.md
Identify users - Docs
Linking events to specific users enables you to build a full picture of how they're using your product across different sessions, devices, and platforms.
This is straightforward to do when capturing backend events, as you associate events to a specific user using a distinct_id, which is a required argument.
However, in the frontend of a web or mobile app, a distinct_id is not a required argument — PostHog's SDKs will generate an anonymous distinct_id for you automatically and you can capture events anonymously, provided you use the appropriate configuration.
To link events to specific users, call identify:
PostHog AI
Web
posthog.identify(
'distinct_id', // Replace 'distinct_id' with your user's unique identifier
{ email: '[email protected]', name: 'Max Hedgehog' } // optional: set additional person properties
);Android
PostHog.identify(
distinctId = distinctID, // Replace 'distinctID' with your user's unique identifier
// optional: set additional person properties
userProperties = mapOf(
"name" to "Max Hedgehog",
"email" to "[email protected]"
)
)iOS
PostHogSDK.shared.identify("distinct_id", // Replace "distinct_id" with your user's unique identifier
userProperties: ["name": "Max Hedgehog", "email": "[email protected]"]) // optional: set additional person propertiesReact Native
posthog.identify('distinct_id', { // Replace "distinct_id" with your user's unique identifier
email: '[email protected]', // optional: set additional person properties
name: 'Max Hedgehog'
})Dart
await Posthog().identify(
userId: 'distinct_id', // Replace "distinct_id" with your user's unique identifier
userProperties: {
email: "[email protected]", // optional: set additional person properties
name: "Max Hedgehog"
});Events captured after calling identify are identified events and this creates a person profile if one doesn't exist already.
Due to the cost of processing them, anonymous events can be up to 4x cheaper than identified events, so it's recommended you only capture identified events when needed.
How identify works
When a user starts browsing your website or app, PostHog automatically assigns them an anonymous ID, which is stored locally.
Provided you've configured persistence to use cookies or localStorage, this enables us to track anonymous users – even across different sessions.
By calling identify with a distinct_id of your choice (usually the user's ID in your database, or their email), you link the anonymous ID and distinct ID together.
Thus, all past and future events made with that anonymous ID are now associated with the distinct ID.
This enables you to do things like associate events with a user from before they log in for the first time, or associate their events across different devices or platforms.
Using identify in the backend
Although you can call identify using our backend SDKs, it is used most in frontends. This is because there is no concept of anonymous sessions in the backend SDKs, so calling identify only updates person profiles.
Best practices when using identify
1. Call identify as soon as you're able to
In your frontend, you should call identify as soon as you're able to.
Typically, this is every time your app loads for the first time, and directly after your users log in.
This ensures that events sent during your users' sessions are correctly associated with them.
You only need to call identify once per session, and you should avoid calling it multiple times unnecessarily.
If you call identify multiple times with the same data without reloading the page in between, PostHog will ignore the subsequent calls.
2. Use unique strings for distinct IDs
If two users have the same distinct ID, their data is merged and they are considered one user in PostHog. Two common ways this can happen are:
Your logic for generating IDs does not generate sufficiently strong IDs and you can end up with a clash where 2 users have the same ID.
There's a bug, typo, or mistake in your code leading to most or all users being identified with generic IDs like
null,true, ordistinctId.
PostHog also has built-in protections to stop the most common distinct ID mistakes.
3. Reset after logout
If a user logs out on your frontend, you should call reset() to unlink any future events made on that device with that user.
This is important if your users are sharing a computer, as otherwise all of those users are grouped together into a single user due to shared cookies between sessions.
We strongly recommend you call reset on logout even if you don't expect users to share a computer.
You can do that like so:
PostHog AI
Web
posthog.reset()iOS
PostHogSDK.shared.reset()Android
PostHog.reset()React Native
posthog.reset()Dart
Posthog().reset()If you also want to reset the device_id so that the device will be considered a new device in future events, you can pass true as an argument:
Web
PostHog AI
posthog.reset(true)4. Person profiles and properties
You'll notice that one of the parameters in the identify method is a properties object.
This enables you to set person properties.
Whenever possible, we recommend passing in all person properties you have available each time you call identify, as this ensures their person profile on PostHog is up to date.
Person properties can also be set being adding a $set property to a event capture call.
See our person properties docs for more details on how to work with them and best practices.
5. Use deep links between platforms
We recommend you call identify as soon as you're able, typically when a user signs up or logs in.
This doesn't work if one or both platforms are unauthenticated. Some examples of such cases are:
Onboarding and signup flows before authentication.
Unauthenticated web pages redirecting to authenticated mobile apps.
Authenticated web apps prompting an app download.
In these cases, you can use a deep link on Android and universal links on iOS to identify users.
Use
posthog.get_distinct_id()to get the current distinct ID. Even if you cannot call identify because the user is unauthenticated, this will return an anonymous distinct ID generated by PostHog.Add the distinct ID to the deep link as query parameters, along with other properties like UTM parameters.
When the user is redirected to the app, parse the deep link and handle the following cases:
The user is already authenticated on the mobile app. In this case, call
posthog.alias()with the distinct ID from the web. This associates the two distinct IDs as a single person.The user is unauthenticated. In this case, call
posthog.identify()with the distinct ID from the web. Events will be associated with this distinct ID.
As long as you associate the distinct IDs with posthog.identify() or posthog.alias(), you can track events generated across platforms.
Further reading
Community questions
Ask a question
Was this page useful?
HelpfulCould be better
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- PostHog
- Publisher
- PostHog (Official)
- Source
- PostHog/skills · skills/posthog/integration/skills/react-react-router-7-framework · commit a5d30e7
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- PostHog/skills
AutoGineer is not affiliated with or endorsed by PostHog or PostHog.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download integration-react-react-router-7-framework.zip