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
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 featureflipper[:search].activate(:boolean)flipper[:search].deactivate(:boolean)flipper[:search].gate_activated?(:boolean)flipper[:search].gate(:boolean).activateflipper[:search].gate(:boolean).deactivateflipper[:search].gate(:boolean).activated?
deactivate should clear any adapter values for the gate
ui actions should not work for deactivated
api actions should not work for deactivated
dsl actions should not work for deactivated
The text was updated successfully, but these errors were encountered:
I was trying to do in memory first and avoid adapter stuff, but there really is no way. You have to at least involve the adapter when deactivating, or you end up with weird state in the UI. For example, let's say you enable an actor, then deactivate the actors gate, the feature shows up as partially enabled, but that isn't true. Because the gate is deactivated, it is actually disabled. The way to fix that is to clear all gate values when deactivating a gate. The problem with that is that there is no adapter method to clear all values for a gate. Currently it only works to clear a single value for a gate. That means we need a new method for the adapters to clear all values. The alternative is to do a get and then a disable for each value (ie: get all actors and disable each).
activate/deactivate also have to permeate the code. feature needs to know what gates are active before it does anything (enable, disable, etc.). The UI needs to know so it can hide things and deny certain actions. The API needs the same.
I think overall what is bothering me is that it is in memory and not persisted in the adapters, but persisting in the adapters means it is a little harder/annoying to build adapters. Perhaps that is fine since most people will use one of the core adapters.
Decided to leave some notes as I'm going to shelf this for a sec to think about it. If anyone has thoughts please let me know.
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:
The text was updated successfully, but these errors were encountered: