IS-322 Setup GrowthBook for FE

[harishv7]

Problem

We are currently feature flagging using env variables which can get messy as we rollout more features. We also do not have an easy way to do things like percentage rollouts.

Closes IS-322

Solution

This PR introduces GrowthBook as a feature flagging system. It sets up some basic code that intialises the SDK and auto-fetches values when they change. It also sets user attributes to the SDK so that we can perform experiments in future.
Note that attributes are not sent to the cloud but rather stay within the local app.

The actual values of the targeting attributes (e.g. the user ids, emails, etc.) are never sent to GrowthBook. They are only stored in memory locally within the SDK. This architecture eliminates huge potential security holes and keeps your user's PII safe and secure.

Source: https://docs.growthbook.io/features/targeting

We also introduce a constants file which mirrors the FE-related flags as it is on GrowthBook for consistent referencing.

Breaking Changes

• Yes - this PR contains breaking changes
  • Details ...
• No - this PR is backwards compatible

Tests

Part 1 - Basic Usage

• Create a feature flag on GrowthBook - either boolean or string or object
• Use useGrowthBook hook to get the GB instance
• Use the useFeatureIsOn or useFeatureValue hooks to retrieve the created flag
• Perform a conditional render inside one of our pages (e.g. render Hello if flag is true, else render World)

Part 2 - Attribute Setting

• Pick an attribute of your account to test, e.g. userId
• Ensure this exists on GrowthBook control panel, else add it
• Select a feature flag to test experimenting
• Modify the feature flag, under Dev environment, to use a forced value
• Enable a unique value specific to your chosen attribute
• Perform a conditional render similar to part 1. This should work
• Remove the forced value option and re-test to ensure you get the default value

Deploy Notes

New environment variables:

• REACT_APP_GROWTHBOOK_CLIENT_KEY : this is required for GrowthBook SDK to connect with the cloud

New dependencies:

• @growthbook/growthbook-react: GrowthBook SDK

[seaerchin]

minor comments

[seaerchin]

this is never set to true - wdyt about removing this argument from getGrowthBookInstance and setting it based on whether REACT_APP_ENV === LOCAL_DEV

[harishv7]

I thought about that but in our local dev, our react env is not LOCAL_DEV as per 1PW

Also the intended use is that if devs need this, they add the true to the constructor in App.jsx and by default it will remain false

[seaerchin]

hmm, my main worry is that this value should be true by default. this will result in q abit of overhead when switching between branches, for example (have to stash, switch, pop etc), which is why i thought it might make sense to dynamically compute this on a per env basis.

the tradeoff we're making here seems to be the time taken to standardise REACT_APP_ENV versus how often this might be swapped to true.

if it makes sense for this to be false by default, feel free to resolve this comment. otherwise, maybe just put a message out in the slack channel to standardise this would be ok toO!

[harishv7]

@seaerchin This option should definitely be false by default to prevent accidental commits or pushes which may pose a higher risk. The docs state:

To avoid exposing all of your internal feature flags and experiments to users, we recommend setting this to false in production in most cases.

I wanted the act of turning this on to be a conscious choice.

But if you are worried about the manual overhead and prevent a more dynamic setting, we could just do this:

export const getGrowthBookInstance = (clientKey: string) => {
  // disable for staging and production
  const isDev =
    process.env.REACT_APP_ENV !== "staging" &&
    process.env.REACT_APP_ENV !== "production"

  return new GrowthBook({
    apiHost: GROWTHBOOK_API_HOST,
    clientKey,
    enableDevMode: isDev, // enable only for local dev
  })
}

Wdyt?

[seaerchin]

oh cos that's the production flag - so imagine if you always want to see the new dev stuff, you'd always need to stash then pop

[seaerchin]

more inclined to do what you've laid out above - with the only caveat being that we align localDev cos got (non dev) envs that we might wanna have - eg: uat/vapt

[harishv7]

Yea exactly, so we need to be firm on the definition and there could be future cases where we introduce new environments. To be on the safe side, the flag needs to be a whitelist (assert if specific environment exists) rather than asserting some environment does not match

[seaerchin]

can, sounds good! i'll approve it first - feel free to merge once isDev flag is in

[harishv7]

added