Skip to content
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

Allow customizing which gates are used per feature #121

Open
4 tasks
jnunemaker opened this issue May 10, 2016 · 1 comment
Open
4 tasks

Allow customizing which gates are used per feature #121

jnunemaker opened this issue May 10, 2016 · 1 comment

Comments

@jnunemaker
Copy link
Collaborator

jnunemaker commented May 10, 2016

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?
  • 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
@jnunemaker jnunemaker self-assigned this May 10, 2016
@jnunemaker
Copy link
Collaborator Author

I've got a branch going for this, but something doesn't feel right.
https://github.com/jnunemaker/flipper/compare/custom-gates

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant