feat: Add Flagsmith Provider

[kyle-ssg]

This PR

Adds a Flagsmith Provider

Notes

• This has been tested and has corresponding examples in Standard, React, SSR and React Native frameworks. Sample applications provided here.
• Flagsmith separates remote configuration from the enabled state, therefore resolveBooleanEvaluation checks the enabled state and others read a feature's remote configuration.

How to test

• Jest tests provided

[kyle-ssg]

Didn't expect any lint issues, AFAIK I've resolved this here

[lukas-reining]

This looks really good! Added some comments about the provider name and type nits.

[toddbaert]

Looks really good. Left some suggestions.

[beeme1mr]

Thanks @kyle-ssg, I'll rereview today. Would you like me to publish to npm if everything looks good?

[kyle-ssg]

Thanks @kyle-ssg, I'll rereview today. Would you like me to publish to npm if everything looks good?

I'm going to be doing a release of the flagsmith SDK to support a couple improvements here. I think I just need clarity on this. I'll keep in draft until I get the SDK release out.

[kyle-ssg]

I've implemented all of the suggested changes and we have a couple improvements upstream ready to help out but I'm finding a bit of an issue with the provider. I don't think it's a blocking issue as I've worked around it in the examples I've made, but this still caught me out.

In attempting the following in an angular application

    OpenFeature.addHandler(ProviderEvents.ConfigurationChanged, handleFlags);
    OpenFeature.addHandler(ProviderEvents.Error, handleFlagsError);
    OpenFeature.setProvider(flagsmithClientProvider)

It works for the most part except It looks like ProviderEvents.ConfigurationChanged doesn't trigger if client.initialise is immediately ready (which is the case if cache is retrieved). Triggering a ProviderEvents.Ready event prior to the ProviderEvents.ConfigurationChanged has no effect. I'm guessing it's essentially due to initialize not resolving prior to the events being emitted.

Im aware that I could do the following, but is there anything else?

• await setProviderAndWait but then I don't get feature metadata
• setup a 1 time ProviderEvents.Ready but similar issue and it adds complexity to the consumer application
• set setTimeout(()=>{emitEvents},0) in the provider. This does work but will result in a flicker
• Detect that the provider is immediately ready by checking the status after setProvider but it seems there's no way to access event metadata.

ConfigurationChanged.mov

[kyle-ssg]

Ok, I think this is ready to go!

[beeme1mr]

Nice job, looks great!

[toddbaert]

I've implemented all of the suggested changes and we have a couple improvements upstream ready to help out but I'm finding a bit of an issue with the provider. I don't think it's a blocking issue as I've worked around it in the examples I've made, but this still caught me out.

In attempting the following in an angular application

    OpenFeature.addHandler(ProviderEvents.ConfigurationChanged, handleFlags);
    OpenFeature.addHandler(ProviderEvents.Error, handleFlagsError);
    OpenFeature.setProvider(flagsmithClientProvider)

It works for the most part except It looks like ProviderEvents.ConfigurationChanged doesn't trigger if client.initialise is immediately ready (which is the case if cache is retrieved). Triggering a ProviderEvents.Ready event prior to the ProviderEvents.ConfigurationChanged has no effect. I'm guessing it's essentially due to initialize not resolving prior to the events being emitted.

Im aware that I could do the following, but is there anything else?

• await setProviderAndWait but then I don't get feature metadata
• setup a 1 time ProviderEvents.Ready but similar issue and it adds complexity to the consumer application
• set setTimeout(()=>{emitEvents},0) in the provider. This does work but will result in a flicker
• Detect that the provider is immediately ready by checking the status after setProvider but it seems there's no way to access event metadata.

ConfigurationChanged.mov

Your assumptions here are all correct, and the solutions are valid. I'll think about this a bit... there may be something that can be done in the SDK but it seems like a bit of an edge case (is it expected or important that you get a change event immediately after becoming ready?)

I guess that in a real-world scenario, if this change event was indeed the result of a change in the remote system, it's just as likely that the change would have occurred before the provider is connected, in which case it would of course not be received. Is this just part of a test scenario?

[toddbaert]

I think this looks great.

[toddbaert]

@kyle-ssg I am merging this. Nice work and thanks, as always. A release PR will be opened which I will not merge until you (or Flagsmith other folks) approve it.

[kyle-ssg]

Your assumptions here are all correct, and the solutions are valid. I'll think about this a bit... there may be something that can be done in the SDK but it seems like a bit of an edge case (is it expected or important that you get a change event immediately after becoming ready?)

I guess that in a real-world scenario, if this change event was indeed the result of a change in the remote system, it's just as likely that the change would have occurred before the provider is connected, in which case it would of course not be received. Is this just part of a test scenario?

Yes and no, it was part of an example app where I rely on changes to push to an array of logs to demonstrate OpenFeature. With how things work currently I think all apps will have to just treat the first ready as a change rather than relying on a single event. I think what I was trying to do relied to heavily on the meta that gets returned in the events, really if people are doing that they may as well just query the provider directly if they need info from it.

[kyle-ssg]

@kyle-ssg I am merging this. Nice work and thanks, as always. A release PR will be opened which I will not merge until you (or Flagsmith other folks) approve it.

Awesome, I'm excited to use it!