Adds PostHog back into the NextJS build

[jkachel]

What are the relevant tickets?

Closes https://github.com/mitodl/hq/issues/5411

Description (What does it do?)

The PostHog integration was not implemented in the NextJS build of Learn. This adds it back:

• Specifying the PostHog project API key and root URL (this is actually technically new)
• The root-level PostHogProvider, initialized only if there's an API key set
• Bootstrapping the provider with feature flag settings via .env if we want to do that, and customizing the prefix for those flags
• Capturing both automatic PostHog events and lrd_view events

Any future work that gets pulled in and uses the PostHog hook or components should now "just work" too. (Unless it's like the lrd_view code, which checks to see if PostHog is there or not.)

Screenshots (if appropriate):

Components when not enabled:

Components and settings when enabled (this is with a test flag added too):

How can this be tested?

Automated tests should pass. This includes a couple for LearningResourceDrawer that were marked as skip because there wasn't PostHog support yet.

Set the required environment variables:

• NEXT_PUBLIC_POSTHOG_PROJECT_API_KEY - the PostHog project API key

Set the optional environment variables:

• NEXT_PUBLIC_POSTHOG_API_HOST - the PostHog API host; defaults to https://us.i.posthog.com. Don't change this unless you have your own PostHog instance running.
• NEXT_PUBLIC_POSTHOG_FEATURE_PREFIX - the prefix to use for feature flags, defaults to FEATURE_
• NEXT_PUBLIC_FEATURE_some_flag_name - customize the lower case bit, and change FEATURE_ if you set the prefix above; set this to something you'll recognize

With at least the required variable set, you should see the PostHogProvider show up in the React components list as in the screenshots. Additionally, you should start to see events flowing into PostHog as you start doing things, including lrd_view events (which fire when you open a learning resource drawer).

If you've bootstrapped some feature flags, you should see those get populated in the PostHogProvider options. We don't have any configured flags right now - you can manually test this by adding something that's flagged out to an existing page, but it's probably sufficient to see the options passed into the provider correctly.

If you want to test the API host setting, you can maybe point it to something like catch-webhooks to make sure it's trying to hit the right place.

[jkachel]

pre-commit.ci run

[ChristopherChudzicki]

Works great. Two small requests.

[ChristopherChudzicki]

I think we should avoid adding to the webpack config unless we really need to, and NextJS has an env key for this... Could processFeatureFlags return the bootstrapFeatureFlags, and then do:

const nextConfig = {
  webpack: { ... } // leave as is... I'm pretty sure we can get rid of it entirely, but no need to futz with it here.
  env: {
    FEATURE_FLAGS: JSON.stringify(bootstrapFeatureFlags)
  }
  ...
}

[ChristopherChudzicki]

What would you think of doing something like

const ConfiguredPHProvider: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  const apiKey = process.env.NEXT_PUBLIC_POSTHOG_PROJECT_API_KEY || ""

  const apiHost =
    process.env.NEXT_PUBLIC_POSTHOG_API_HOST || "https://us.i.posthog.com"
  const featureFlags = JSON.parse(process.env.FEATURE_FLAGS || "")

  const postHogOptions = {
    api_host: apiHost,
    bootstrap: {
      featureFlags: featureFlags,
    },
  }
  if (!apiKey) return children
  return (
    <PostHogProvider apiKey={apiKey} options={postHogOptions}>
      {children}
    </PostHogProvider>
  )
}

?

Then ConfiguredPHProvider can handle the conditional itself + configuration.

Partly suggesting this to encapsulate it, but partly because we could run into the same situation in future with other providers, and as-structured I think it would get awkward with more than 1.

[ChristopherChudzicki]

"" is falsy, so you can just check !apiKey

[ChristopherChudzicki]

Is NEXT_PUBLIC_POSTHOG_PERSONAL_API_KEY used for anything?

[jkachel]

No, and actually that shouldn't be in the build since it's the actually secret one. I pulled it (and the project ID; we don't use that either, PostHog figures it out just from the project key).

[jkachel]

90ad486 addresses the comments. This does pull the PostHog provider stuff into its own component, which makes the providers.tsx a good bit cleaner.

[ChristopherChudzicki]

👍