Feature flag module

[drewvolz]

Would we benefit from having a centralized feature flag system? We could enable experiments for ourselves, toggle different styles, switch between implementations of layouts.

I know we don't publish often enough to have live feature flags be toggled in production but at least in development we could put features that we're wanting to iterate upon behind a toggle.

I am thinking this would involve

• A list row in settings
• A searchable and grouped section list of features
• Default and experimental values
• Store of saved feature set in redux (backed by something more persistent? localstorage?)
• Branching across the app itself to split returned values based upon feature flag value

[rye]

Would we benefit

Probably! I like the idea of this. This would enable us to try and do more deployments more often with subtle changes, so we can actually see these things in the beta build. It would also let us ask students to test a feature (e.g. by going into the settings and checking it) while they could still have a stable experience.

Something like

if (hasFeatureEnabled("aao.settings.list_row")) {
    <NewFancyComponentUsingListRowStuff />
} else {
    <OldNotSoFancyComponent />
}

A couple of additional thoughts:

• Invisible features are kinda annoying in principle but would probably make sense. Having the ability to "remote-toggle" some functionality would be nice.

• A/B testing? Probably not worth it, but it could use a similar system.

• I think the app should include a "manifest" of features it supports, and the user can control which of these is enabled in the settings. Some (if we choose) are hidden from the user but still included in the manifest. The manifest (or just the list of "enabled features") could be sent along to the API, to enable that info to be used elsewhere.

  • For example, maybe we figure out how to cache data locally on the client without any weirdness, but we still want the option to compare and bail — maybe this could be used to enable some kind of ETag processing so the server only returns a "diff" of data instead?
  • Would probably be nice to have a unified way to refer to features. Namespacing is one of them.

Whatever we use for storing feature flags, I'd like to make sure that "Reset Everything" works (takes you back to the default feature set). Ideally, we wouldn't have to worry about async when checking feature flags.

[rye]

(One side note: I think this would be useful in production, too. If we could reduce the time between production releases, I think that'd be ideal — having gates preventing people from hitting potentially-buggy code is one way to make that easier. We still have to consider things like dependencies, though [is there a way to toggle between npm packages?! that'd be sweet])