feat(react): add FeatureFlag component #1164

weyert · 2025-04-09T00:12:00Z

This PR

Introduces the FeatureFlag component for React that allow using feature flags in a declarative manner

Related Issues

No ticket

Notes

Maybe consider adding a similar component for other supported frameworks?

Follow-up Tasks

How to test

I have written unit tests to cover the main features of the component

Introduces the FeatureFlag component for React that allow using feature flags in a declarative manner Signed-off-by: Weyert de Boer <[email protected]>

toddbaert · 2025-04-10T08:24:29Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * The key of the feature flag to evaluate.
+   */
+  featureKey: string;


I think this should be called key... or possibly flagKey, but I think that's redundant given the name of the component.

key is reserved in React: https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key

Keys tell React which array item each component corresponds to, so that it can match them up later. This becomes important if your array items can move (e.g. due to sorting), get inserted, or get deleted. A well-chosen key helps React infer what exactly has happened, and make the correct updates to the DOM tree.

so I would vote for flagKey

toddbaert · 2025-04-10T08:25:36Z

packages/react/src/declarative/FeatureFlag.tsx

+  featureKey: string;
+
+  /**
+   * Optional value to match against the feature flag value.


Please specify here exactly what comparison is used\ (==vs ===, etc).

if we do the default mentioned below, we can just describe it as By default, strict equality is used

toddbaert · 2025-04-10T08:26:36Z

packages/react/src/declarative/FeatureFlag.tsx

+   * If a boolean, it will check if the flag is enabled (true) or disabled (false).
+   * If a string, it will check if the flag variant equals this string.
+   */
+  match?: string | boolean;


I think it would be really cool to add support for a predicate function that accepts the EvaluationDetails so people can specify exactly how to match.

I think it would be really cool to add support for a predicate function that accepts the EvaluationDetails so people can specify exactly how to match.

+1

Also with this, you could make this function work for all the types.
And it could have a default that would be

function equals<T>(expected: T, actual: EvaluationDetails<T>){ return expected === actual.value }

And for objects we could actually make this required if we wanted as this default does not make much sense here.
What do you think @weyert @toddbaert?

Actually ya, I think that's a great idea.

toddbaert · 2025-04-10T08:29:52Z

packages/react/src/declarative/FeatureFlag.tsx

+   * Default value to use when the feature flag is not found.
+   */
+  // eslint-disable-next-line @typescript-eslint/no-explicit-any
+  defaultValue: any;


You can use the FlagValue type available from the SDK.

With the predicate from above this could be generic.
The whole component would become nicely typed then as the same type param can be used for the predicate then, so it will always fit the default value.

toddbaert · 2025-04-10T08:30:29Z

packages/react/src/declarative/FeatureFlag.tsx

+   * Can be a React node or a function that receives flag query details and returns a React node.
+   */
+  // eslint-disable-next-line @typescript-eslint/no-explicit-any
+  children: React.ReactNode | ((details: FlagQuery<any>) => React.ReactNode);


Same as https://github.com/open-feature/js-sdk/pull/1164/files#r2036811527 I think.

toddbaert · 2025-04-10T08:36:25Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * Optional content to render when the feature flag condition is not met.
+   */
+  fallback?: React.ReactNode;


I think if we are going to only have one alternative child (fallback) we definitely need to do this, so that users can have control over to render this in very specific situations (evaluation errors, reasons, etc).

The alternative (which I don't like as muich) would be to also specify error components, etc... but I think that isn't as good.

cc @beeme1mr @lukas-reining

The alternative (which I don't like as muich) would be to also specify error components, etc... but I think that isn't as good.

I think for it feels a little more idiomatic to have the matcher that is also able to match for error, as you said @toddbaert.
But both could work for me.

toddbaert · 2025-04-10T08:37:05Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * If true, inverts the condition logic (renders children when condition is NOT met).
+   */
+  negate?: boolean;


I'm not sure if this is needed if we do this: https://github.com/open-feature/js-sdk/pull/1164/files#r2036805701 I would recommend getting rid of this, then users can white their own invert.

toddbaert

This is really cool. I really like the idea and the concepts. I've made a few minor proposals that I think simply the API but also make it slightly more flexible.

lukas-reining

This is a good idea!
Left some thought before approving :)

lukas-reining · 2025-04-14T18:58:24Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * The key of the feature flag to evaluate.
+   */
+  featureKey: string;


key is reserved in React: https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key

Keys tell React which array item each component corresponds to, so that it can match them up later. This becomes important if your array items can move (e.g. due to sorting), get inserted, or get deleted. A well-chosen key helps React infer what exactly has happened, and make the correct updates to the DOM tree.

so I would vote for flagKey

lukas-reining · 2025-04-14T19:01:50Z

packages/react/src/declarative/FeatureFlag.tsx

+   * If a boolean, it will check if the flag is enabled (true) or disabled (false).
+   * If a string, it will check if the flag variant equals this string.
+   */
+  match?: string | boolean;


I think it would be really cool to add support for a predicate function that accepts the EvaluationDetails so people can specify exactly how to match.

+1

Also with this, you could make this function work for all the types.
And it could have a default that would be

function equals<T>(expected: T, actual: EvaluationDetails<T>){ return expected === actual.value }

And for objects we could actually make this required if we wanted as this default does not make much sense here.
What do you think @weyert @toddbaert?

lukas-reining · 2025-04-14T19:04:25Z

packages/react/src/declarative/FeatureFlag.tsx

+   * Default value to use when the feature flag is not found.
+   */
+  // eslint-disable-next-line @typescript-eslint/no-explicit-any
+  defaultValue: any;


With the predicate from above this could be generic.
The whole component would become nicely typed then as the same type param can be used for the predicate then, so it will always fit the default value.

lukas-reining · 2025-04-14T19:08:38Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * Optional content to render when the feature flag condition is not met.
+   */
+  fallback?: React.ReactNode;


The alternative (which I don't like as muich) would be to also specify error components, etc... but I think that isn't as good.

I think for it feels a little more idiomatic to have the matcher that is also able to match for error, as you said @toddbaert.
But both could work for me.

lukas-reining · 2025-04-14T19:08:50Z

packages/react/src/declarative/FeatureFlag.tsx

+  /**
+   * If true, inverts the condition logic (renders children when condition is NOT met).
+   */
+  negate?: boolean;


lukas-reining · 2025-04-14T19:10:19Z

packages/react/src/declarative/FeatureFlag.tsx

+  featureKey: string;
+
+  /**
+   * Optional value to match against the feature flag value.


if we do the default mentioned below, we can just describe it as By default, strict equality is used

weyert requested review from a team as code owners April 9, 2025 00:12

feat(react): add FeatureFlag component

e6614c0

Introduces the FeatureFlag component for React that allow using feature flags in a declarative manner Signed-off-by: Weyert de Boer <[email protected]>

weyert force-pushed the add-feature-flag-component branch from b22a3e3 to e6614c0 Compare April 9, 2025 00:13

toddbaert reviewed Apr 10, 2025

View reviewed changes

toddbaert requested review from beeme1mr, jonathannorris and lukas-reining April 10, 2025 08:46

lukas-reining reviewed Apr 14, 2025

View reviewed changes

feat(react): add FeatureFlag component #1164

Are you sure you want to change the base?

feat(react): add FeatureFlag component #1164

Uh oh!

Conversation

weyert commented Apr 9, 2025

This PR

Related Issues

Notes

Follow-up Tasks

How to test

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

toddbaert left a comment

Choose a reason for hiding this comment

Uh oh!

lukas-reining left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!