feat: suspense support, client scoping, context-sensitive re-rendering

[toddbaert]

Adds a few react features:

• <Suspense /> support: components using feature flags will trigger suspense for easy loaders/spinners
• Ability to specify name for provider scope: <OpenFeatureProvider name="my-provider">

Important

Please see here for the latest changes to the demo application using these features (note that we won't be able to merge these demos until this is released).

Important

Also note I've added no tests, which is certainly not my MO. I will add them to this PR once there's an agreement on this behavior and implementation.

gif from the demo app:

⚠️ I want to add another feature here to support re-rendering on context changes. That requires this to be merged.

[beeme1mr]

I know React uses the term Provider but we may want to come up with an alternative since a provider already has a specific meaning in OpenFeature.

[toddbaert]

I know React uses the term Provider but we may want to come up with an alternative since a provider already has a specific meaning in OpenFeature.

@beeme1mr I think I disagree. Conveniently the React provider is easily associated with a OpenFeature Provider via the name... so in some respects it actually works well to blur these lines. Moreover, in React, providers are a very explicit thing, and if we don't use that name I think people would be confused.

Maybe somebody else has an opinion on this point specifically. cc @lukas-reining @thomaspoignant @kinyoklion

[weyert]

I know React uses the term Provider but we may want to come up with an alternative since a provider already has a specific meaning in OpenFeature.

@beeme1mr I think I disagree. Conveniently the React provider is easily associated with a OpenFeature Provider via the name... so in some respects it actually works well to blur these lines. Moreover, in React, providers are a very explicit thing, and if we don't use that name I think people would be confused.

Maybe somebody else has an opinion on this point specifically. cc @lukas-reining @thomaspoignant @kinyoklion

No strong feelings about it but you could always call it OpenFeatureContextProvider

[toddbaert]

I know React uses the term Provider but we may want to come up with an alternative since a provider already has a specific meaning in OpenFeature.

@beeme1mr I think I disagree. Conveniently the React provider is easily associated with a OpenFeature Provider via the name... so in some respects it actually works well to blur these lines. Moreover, in React, providers are a very explicit thing, and if we don't use that name I think people would be confused.
Maybe somebody else has an opinion on this point specifically. cc @lukas-reining @thomaspoignant @kinyoklion

No strong feelings about it but you could always call it OpenFeatureContextProvider

Ya, I'd be fine with that, but unfortunately we also use Context in OpenFeature 😬

[lukas-reining]

No strong feelings about it but you could always call it OpenFeatureContextProvider.

Also no strong feelings.
OpenFeatureProvider feels the best to me. For people working on React it seems to be the most intuitive and as it is only used in the JSX context, I also feel that people won't confuse this for the OpenFeature provider concept.

[beeme1mr]

You've convinced me. I'm fine with OpenFeatureProvider.

[thomaspoignant]

I agree with @lukas-reining OpenFeatureProvider is simple enough.

[lukas-reining]

Change looks good to me and is a nice addition.
Left two comments with open questions.

[weyert]

LGTM

[jonathannorris]

@toddbaert / @beeme1mr one question we had taking a look at this and thinking through the suspense behaviour, what happens when the context is updated? does the SDK go back into a "pending" state?

[toddbaert]

@toddbaert / @beeme1mr one question we had taking a look at this and thinking through the suspense behaviour, what happens when the context is updated? does the SDK go back into a "pending" state?

That's a very interesting question...

When the context is set, the SDK doesn't change the provider state (and has no such state itself) - but some providers might go into the ProviderStatus.STALE state while they await new flag values for the updated context. Others (particularly those that cache rulesets) may not.

This has a few implications, and I think we are missing some guidance and possibly some semantics around the on context changed handler and provider state/events. I will think about this some more today, and possibly create an issue and a PR in spec. Thanks for the thoughtful consideration @jonathannorris !

[toddbaert]

@toddbaert / @beeme1mr one question we had taking a look at this and thinking through the suspense behaviour, what happens when the context is updated? does the SDK go back into a "pending" state?

That's a very interesting question...

When the context is set, the SDK doesn't change the provider state (and has no such state itself) - but some providers might go into the ProviderStatus.STALE state while they await new flag values for the updated context. Others (particularly those that cache rulesets) may not.

This has a few implications, and I think we are missing some guidance and possibly some semantics around the on context changed handler and provider state/events. I will think about this some more today, and possibly create an issue and a PR in spec. Thanks for the thoughtful consideration @jonathannorris !

OK, so I've implemented another feature which allows for re-renders with the emission of ProviderEvents.ContextChanged events. This means that once the context is reconciled, we can re-render components, which is a very important thing to have. Currently, there's no "pending" state; the aforementioned event is only emitted once the provider has fully reconciled it's new context (or it fails to, in which case an error is emitted).