Comments (5)
If we can decide on a path I'm fine doing the change and submitting a PR.
from unleash-client-go.
I'm actually leaning more towards the second path because we also need the underlying api.Feature
to know what type of feature it is (see #162). We will have some special logic for kill-switch-type features. In #161 I mentioned it might be useful to return the api.Feature
in the api.StrategyResult
method. If we added a new method that returned api.StrategyResult
with a Feature
then that would solve both of those.
from unleash-client-go.
Describe the feature request
Currently there's no way with a single call to differentiate between a feature being disabled and no variants on the feature. Both of those cases return the default variant. Ideally there would be a call that returns
(variant, enabled)
.Background
We would like to make a single call and understand if a feature is enabled and what variant is applicable, if any. Instead we have to make 2 calls to understand the distinction. I'm surprised that this hasn't been brought up already and I'm curious how others are using this library in production with variants.
Solution suggestions
There are 2 potential solutions I see:
- Fixing the fallback options. Currently the descriptions of WithVariantFallback and WithVariantFallbackFunc are wrong. Those are actually used when a feature is not found. I filed this as WithVariantFallback and WithVariantFallbackFunc are called when feature isn't found #160. A new option could be added that is used to fallback when a feature is not found and the existing fallbacks could be correctly used when there are no variants on the feature. This would be a breaking change though, but I'm not sure how many people realize the existing options are not doing what they say they do.
- Add a new method that returns a variant and if it's enabled or not. This could also return a struct similar to the StrategyResult struct so it could be added to in the future if more things need to be returned.
Personally we're fine with either but the options being broken does seem like it should be fixed and might lend itself to just adding a new option.
Thanks for pointing this out, it's definitely a gap we're looking to close. When this SDK was first created it was based on our node-client, which had this interface already. As we have SDKs in multiple different languages, we do strive to keep the API surface as similar as possible, both to avoid SDK bloat but also to keep the mental model clean across language boundaries.
Expanding the API for one SDK is really something we want to try to avoid. Especially since we have started this journey already in our python SDK here. Would it be acceptable for now to add a similar property to the GetVariant response?
Look forward to hearing from you
from unleash-client-go.
Would it be acceptable for now to add a similar property to the GetVariant response?
You're talking about adding IsFeatureEnabled
to api.Variant
? Yes, that seems fine. I appreciate the quick reply!
from unleash-client-go.
from unleash-client-go.
Related Issues (20)
- Is there a way to get all the feature flags for a project, not just one at a time? HOT 2
- Proposal: be more strict about WithListener HOT 4
- Implement Global Segments
- (Feature Request) Enable passing api.Feature instead of a string to an alternative of IsEnabled HOT 12
- Update link to GoDoc HOT 2
- openfeature HOT 2
- infinitely blocked in metrics.count with gitlab HOT 3
- Back-off strategy for calling Unleash HOT 2
- Missing v3.9.0 Release Notes HOT 1
- WithVariantFallback and WithVariantFallbackFunc are called when feature isn't found HOT 3
- Avoid fetching feature again in GetVariant HOT 4
- Add Type to api.Feature HOT 1
- Add app & environment variant override support HOT 3
- fix: GetVariant does not accept custom context HOT 1
- Publicly expose the default Strategies for faster and more advanced Strategies. HOT 2
- Unleash context in readme direct to 404 HOT 1
- Why is not options passed when calling GetVariant? HOT 1
- Missing testdata results in failed build HOT 3
- Not able to set Environment in Client HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from unleash-client-go.