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
I saw there is already an API part in this repository, but I wonder how much should we really expose as API. For example, in the first step I would suggest we define a read-only API and handle all the writing/updating from inside this module.
For Read we should I think only have a single function which returns active/inactive, and handle everything else in the background.
In the next step we can think what kind of People we want to target. Only Developers working on a full Shop, or also module developers. Should other module developers be able to have a soft dependency?
But I dont really see a reason why module developers should need it, so we probably only want to support full shops as target group.
Adding a new Toggle should be easy, and its probably good to default new toggles to "deactivated" to keep the API most simple.
Starting with this, adding a new FeatureToggle should only have a single parameter, its Id/Name. It should be easy to add. The most easy way would be adding on first request, so as soon someone asks if an featureToggle is active, it would be created if not found yet. An alternative would be via setup script, but thats always kind of annoying.
Any comments/opinions for this?
The text was updated successfully, but these errors were encountered:
API correct I don't think we need an extensive public API just yet ( perhaps ever ) as the only method we would want to expose is the isActive ( or different name ).
default all toggles to be deactivated Interesting. What I planned was that any toggle added would be Enabled by default that way people can still deploy without having to check if the module is deactivated. Perhaps a developer mode could be set to mark new toggles as deactivated if present but not sure if / how this might work.
Representation of a simple feature toggle:
id toggleName status
I think this is all that is required in the first instance and then we can start to add additional options for toggle for: IP, Segment etc.
Ben Marks introduced me to Toggle Lib and it would be good for you to review and see if this package could add additional features without having to rebuild additional logic.
I have also creating a milestone and initial roadmap for the project (here)[https://github.com/jamescowie/Magento2-FeatureToggles/wiki/Roadmap] I would be really interested to hear your thoughts on what you would like to see included in the module etc.
I saw there is already an
API
part in this repository, but I wonder how much should we really expose as API. For example, in the first step I would suggest we define a read-only API and handle all the writing/updating from inside this module.For Read we should I think only have a single function which returns active/inactive, and handle everything else in the background.
In the next step we can think what kind of People we want to target. Only Developers working on a full Shop, or also module developers. Should other module developers be able to have a soft dependency?
But I dont really see a reason why module developers should need it, so we probably only want to support full shops as target group.
Adding a new Toggle should be easy, and its probably good to default new toggles to "deactivated" to keep the API most simple.
Starting with this, adding a new FeatureToggle should only have a single parameter, its Id/Name. It should be easy to add. The most easy way would be adding on first request, so as soon someone asks if an featureToggle is active, it would be created if not found yet. An alternative would be via setup script, but thats always kind of annoying.
Any comments/opinions for this?
The text was updated successfully, but these errors were encountered: