feat: add support for feature flags

[joshblack]

Add an exploration for introducing feature flags to @primer/react. This PR introduces a new component, FeatureFlags, that is responsible for enabling or disabling flags in a specific tree of components. It also introduces hooks, useFeatureFlag and useFeatureFlags, as ways for maintainers to determine if a feature is flagged in or not.

<FeatureFlags flags={flags}>
  <ExampleReactApp />
</FeatureFlags>

function ExampleComponent(props) {
  const enabled = useFeatureFlag('enable_new_feature');

  return <button onClick={() => { enabled ? newBehavior() : oldBehavior() }}>...</button>;
}

This PR also includes some docs for how to approach this for things like TypeScript, testing, and (in the future) hopefully I way to interact with flags in Storybook.

Changelog

New

• Add FeatureFlags component
• Add useFeatureFlag hook
• Add useFeatureFlags hook

Changed

Removed

Rollout strategy

• Minor release

Introduce in experimental entrypoint for testing

[changeset-bot]

🦋 Changeset detected

Latest commit: 154d575

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/react	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
packages/react/dist/browser.esm.js	88 KB (0%)
packages/react/dist/browser.umd.js	88.25 KB (0%)

[joshblack]

Note from UI mob pairing: add support for providing a (sync) function to check if something is enabled

[github-actions]

Hi! This pull request has been marked as stale because it has been open with no activity for 60 days. You can comment on the pull request or remove the stale label to keep it open. If you do nothing, this pull request will be closed in 7 days.

[siddharthkp]

Great idea! Love to see it.

Short feedback on usage: I think we should make the first iteration a little simpler for ourselves. I'm a little hesitant to support nested scopes right off the bat because usage in gh/gh can quickly get really hard to debug. (I'm thinking inconsistencies between pages, untested combination of feature flags, single instances of a component used with feature flag or the opposite)

Ideally, I'd like to start with a broad boundary (adjacent to ThemeProvider) and once we have some experience with it (and related tooling), make it more advanced.

Note for future: It would be nice if we had a common ThemeProvider across gh/gh and it was called something like PrimerProvider / PrimerContainer / PrimerBoundary (with exceptions for charting etc.)

[joshblack]

@siddharthkp would love to do something like PrimerApp or some kind of "App-level" component like what you described 👍 it would make it simple to add in things as "defaults" to projects that use Primer as a result.

And happy to defer on nesting if that would be helpful 👍 I think the only thing that felt critical is that we want a set of "default" feature flags (in this case the global ones) and that this should be merged in with what is given at the FeatureFlags level. This seemed important because otherwise call sites to FeatureFlags need to manage all flags and their default value, even if it's unrelated to what is being authored.

[siddharthkp]

Looking good!

I know you're going to write tests, approving in advance