-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose a module for runtime detection of opt-in/opt-out. #10
Comments
@chancancode - Thoughts? |
Oh, also, IMHO we should do both options... |
This should probably also expose whether the user explicitly opted in/out (as opposed to simply accepting the default), so it can be used to address emberjs/ember.js#16849. |
Ya, agreed, though I think that it may need to be a separate API. I think most of the time you just want to know enabled or disabled, but in a somewhat rare set of cases you care if the user explicitly chose the setting or not... |
As there has been no movement on this, Ember Twiddle will be using EmberENV as an intimate api. |
At times, addons will need to know if specific optional features are enabled or not. With the current architecture it is only possible to detect at runtime via
window.EmberENV._SOME_FLAG_HERE
, but we should not encourage that type of coupling toEmberENV
.As I see it we have a few options:
@ember/optional-features
module that can be imported and checked for various opt-in's. This would allow consumers to use an import and conditionals in their code based on a given optional flag value.@ember/optional-features
as a direct dependency. This babel plugin would provide custom build time replacement of@ember/optional-features
based conditionals, and would therefore allow addons to include support for multiple variations of features without bloating the total asset size.The text was updated successfully, but these errors were encountered: