RFC: Support for query params
See original GitHub issueIt would be useful in my app to have feature flags which are switched off but can be switched on via a query param. This would allow specific users to test a feature before it is enabled for all users.
For example www.app.com?enabledFeatures=new-billing,new-settings
would turn on the new-billing
and new-settings
flags.
More details:
- The query param would default to
enabledFeatures=
but can be configured. (I don’t think this could be calledfeatures=
because this would have to be a property on the controller and it might conflict with the service). - This whole query-param option could be switched on or off.
In the future we could also consider:
- Support specifying for each feature flag if it can be toggled via a queryParam
- Support disabling features via query param, although I don’t see this as being as useful…
Please let me know if you think this is a good idea. I’d be happy to submit a PR.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:5
- Comments:5 (3 by maintainers)
Top Results From Across the Web
RFC 3986 Support for Encoding Query Parameters
The REST Adapter supports encoding query parameters in accordance with RFC 3986 standards. The default behavior is to encode the query parameters following ......
Read more >RFC 1808 Relative Uniform Resource Locators - IETF
It is a companion to RFC 1738, "Uniform Resource Locators (URL)" [2], which specifies the syntax and semantics of absolute URLs. A common...
Read more >rfc6920.txt - » RFC Editor
Query Parameters : A "tag=value" list of optional query parameters as are used with HTTP URLs [RFC2616] with a separator character '&' between...
Read more >Query string - Wikipedia
A query string is a part of a uniform resource locator (URL) that assigns values to specified parameters. A query string commonly includes...
Read more >Is a url query parameter valid if it has no value? - Stack Overflow
The URI RFC doesn't mandate a format for the query string. Although it is recognized that the query string will often carry name-value...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for sharing your solution.
I wouldn’t recommend using
Ember.Evented
nor initializers in new code, so I would stick with the first way, for now.We just implemented an augmentation/extension for the
features
service to support query params andsessionStorage
persistence (for tab persistence for FFs), I think a different way would be to have better docs and hooks for enable/disabling features.This way teams can have a dedicated way to initialize and persist FFs with QPs, dynamic HTML Head, server request, etc.
This is our extended
features
service:But, I think that there could be an API using initializers to have an app initializer like and the above implementation would become:
The change would be adding some initialization hook and then using
Ember.Evented
to an event listener fortoggleFeature
(I’m using a single event rather than having separate enable/disable but 🤷🏽)