User request: Improve Next integration
Is your feature request related to a problem?
https://twitter.com/ksaitor/status/1394603262158852099
Describe the solution you'd like
Would be great to:
- Better support for SSR. Especially fallback for posthog.isFeatureEnabled() during SSR.
- Dynamic loading / smaller bundle size.
Hi there. I'm @ksaitor from the tweet above. Would be great to have a better https://github.com/vercel/next.js/ integration:
- Smaller client size bundle size. Currently
import posthog from 'posthog-js'adds ~22kb (after gzip) to base build. - Super excited for built-in feature flags! However, currently they dont go well together with SSR (server side rendering). For example, a typical React component or a Next.js page:
export default function AwesomeComponent({ ...props }) {
if (!posthog.isFeatureEnabled('my-awesome-feature')) {
return <p>New feature launching soon!</p>
}
// awesome new feature implementation below …
^ this will work in browser, but during SSR and build time would fail right away. I realise that isFeatureEnabled relies on cookies, which are not directly accessible in Next during SSR, and perhaps there are some other complicated workarounds that i could do… but it'd be better if that support is done by the authors, since you know better how this works.
p.s. Next.js is very popular, i'm sure you aware. SSR is one of the main reasons why Next is popular, so the workaround shouldn't compromise on these things ideally.
Thank you! Excited to start using Postjog for https://cryptojobslist.com
Hey @ksaitor! Thanks a lot for this! Agree with you that Next.js is an important framework and something that would be good to look into.
Regarding your points:
-
Slimming down
posthog-jsis something we're interested in doing. It's unlikely we'll make an integration for Next that does not leverageposthog-jsunder the hood though. -
We use
posthogwith Gatsby (which also does SSR). We also have leveraged feature flags with it. Essentially, the simplest workaround is to checkposthogexists before trying to doposthog.isFeatureEnabled. This will prevent your build from failing but without a "retry" mechanism doesn't ensure the flag will ever come on (if the call on the client happens before we finished loading feature flags).
However, we do have something for this already, a React hook for feature flags, called useFeatureFlags, this will abstract away the logic of checking if posthog is there and letting you handle feature flags more easily. Here's how it works:
Step 1
Wrap your React app with PostHogProvider, passing it an instance of your initialised PostHog client. This creates an app-wide context to store the client, and other data (in this case, data fetched regarding the feature flags).
import posthog from "posthog-js";
import { PostHogProvider } from "posthog-js/react";
posthog.init("API_KEY", {
api_host: "HOST"
});
ReactDOM.render(
<React.StrictMode>
<PostHogProvider client={posthog}>
<App />
</PostHogProvider>
</React.StrictMode>,
document.getElementById("root")
);
Step 2
- In the component(s) that need to use feature flags, call the
useFeatureFlagshook and do something useful with the return value.
import React from "react";
import { useFeatureFlags } from "posthog-js/react";
export default function ExampleComponent() {
const { enabled: enabledFlags } = useFeatureFlags({
refreshInterval: 10, // Refresh enabled flags every 10 seconds
sendEvent: false, // Disable event sending when checking feature enabled status
});
return enabledFlags.secretFeature ? (
<div>Display secret feature component</div>
) : (
<div>Display default component</div>
);
}
Moved from posthog to posthog-js
We now offer a React provider, useful hooks and a comprehensive guide on how to use PostHog with client side and server side react: https://posthog.com/docs/integrate/third-party/next-js