Currently all gates are used for all features all the time. I've found that sometimes I don't pass in an actor, so the % of actors, actor and group gates don't make sense for the feature. I'd like to be able to deactivate those gates and have that show up in the UI and DSL. In the UI, we could hide the forms for deactivated gates. In the DSL, we could raise if you attempt to enable/disable those gates.
As far as naming, enabled/disabled is pretty dominant in flipper so I don't want to and really can't use them for this. Thinking about it for a bit all I could come up with is activate/deactivate/activated?. enabled/disabled/enabled? are for determining feature enabled-ness and activate/deactivate/activated? would be for determining if the gates should be used when determining feature enabled-ness.
As far as where this should be stored, the easiest thing is to just store it in memory in the code. The stinky thing is that if we do that any place that mounts the UI or API will also need that shared code. I may start with this to see what the feature feels like overall and then look at how to persist it at the adapter level in a way that it doesn't need to be defined in code and will work wherever.
Some code scribbles so I remember:
# will need DSL methods as well, but here is what it would/could look like from feature
flipper[:search].activate(:boolean)
flipper[:search].deactivate(:boolean)
flipper[:search].gate_activated?(:boolean)
flipper[:search].gate(:boolean).activate
flipper[:search].gate(:boolean).deactivate
flipper[:search].gate(:boolean).activated?
Currently all gates are used for all features all the time. I've found that sometimes I don't pass in an actor, so the % of actors, actor and group gates don't make sense for the feature. I'd like to be able to deactivate those gates and have that show up in the UI and DSL. In the UI, we could hide the forms for deactivated gates. In the DSL, we could raise if you attempt to enable/disable those gates.
As far as naming, enabled/disabled is pretty dominant in flipper so I don't want to and really can't use them for this. Thinking about it for a bit all I could come up with is activate/deactivate/activated?. enabled/disabled/enabled? are for determining feature enabled-ness and activate/deactivate/activated? would be for determining if the gates should be used when determining feature enabled-ness.
As far as where this should be stored, the easiest thing is to just store it in memory in the code. The stinky thing is that if we do that any place that mounts the UI or API will also need that shared code. I may start with this to see what the feature feels like overall and then look at how to persist it at the adapter level in a way that it doesn't need to be defined in code and will work wherever.
Some code scribbles so I remember: