You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we have not an easy way to know if a feature flag key is invalid (not present in the datafile).
In the case of the activate method signature we can see that it can throw and one of its possible exceptions is experimentKeyInvalid which serves exactly to that purpose but for experiments.
My suggestion is to provide with the very same functionality but for feature flags.
Right now we can workaround it by doing optimizelyClient.getOptimizelyConfig().featuresMap[feature.rawValue] but it can be VERY slow as getOptimizelyConfig parses all the information each time is called.
I could do a PR if you want.
Benefits
Would be a fast way for clients to provide with default values for feature flags even when those are not yet created in optimizely.
Detail
No response
Examples
No response
Risks/Downsides
The only downside is that by doing it throwable we will force any client integrating the sdk to modify their current implementation to handle any possible exception but on the other hand we would normalize both experiments and feature flags APIs.
The text was updated successfully, but these errors were encountered:
Description
Right now we have not an easy way to know if a feature flag key is invalid (not present in the datafile).
In the case of the
activate
method signature we can see that it can throw and one of its possible exceptions isexperimentKeyInvalid
which serves exactly to that purpose but for experiments.My suggestion is to provide with the very same functionality but for feature flags.
Right now we can workaround it by doing
optimizelyClient.getOptimizelyConfig().featuresMap[feature.rawValue]
but it can be VERY slow asgetOptimizelyConfig
parses all the information each time is called.I could do a PR if you want.
Benefits
Would be a fast way for clients to provide with default values for feature flags even when those are not yet created in optimizely.
Detail
No response
Examples
No response
Risks/Downsides
The only downside is that by doing it throwable we will force any client integrating the sdk to modify their current implementation to handle any possible exception but on the other hand we would normalize both experiments and feature flags APIs.
The text was updated successfully, but these errors were encountered: