3

This question is not on how to actually write such feature flag per-se. But mostly to seek out for recommendations or hints on such system.

The idea is simple:

In order to progressively roll out/in features, we need to fork behaviors.

To do so, we create a featureDescriptionFlag object which contains arrays of strings. If it exist return true, otherwise false

But, also, has to consider:

  • If no flag object exists, returns false as in no flip has ben triggered
  • The ideal condition is to eventually remove all flags

I am refering to feature flag, concepts as described here:

The question

My main concerns on my implementation are the following:

  1. Using a global object to describe the flag feels wrong
  2. When a conditional statement exists, should we cache the outcome for subsequent calls (e.g. executes true first, then somewhere edits the featureDescriptionFlag, then next calls returns false)

Implementation example

This is the first implementation I came up with (see also on jsfiddle):

// WARNING: Requires underscore.js
function featureFlag(flagContainerName, elementKeyToCheck) {
  //console.log('Feature flagging on '+flagContainerName+', with ' + elementKeyToCheck); // DEBUG
  if (_.has(window.featureFlagDescriptor||{}, flagContainerName)) {
     if(_.contains(window.featureFlagDescriptor[flagContainerName]||[], elementKeyToCheck)) {
       //console.log('Disabled by '+flagContainerName+', matching ' + elementKeyToCheck); // DEBUG
       return true;
     }
  }
  return false;
}

Then, a flag description object that we create global

window.featureFlagDescriptor = {someFunction: ['example']};

My concern here is that It may be dangerous to allow such flip, I have alarms in my mind on how this could be exploited.

Later, in a function that has to have two behaviors, we do:

function someFunction(){
  // Code...
  if(featureFlag('someFunction', 'example')) {
    // Work only if flag exist
  } else {
    // Former behavior
  }
}

Conclusion

Any recommendations, improvement proposals?

I have created a jsfiddle on the subject and will eventually make a full working sample.

Community
  • 1
  • 1
renoirb
  • 569
  • 5
  • 15
  • I think your approach is flawed, as by using unobtrusive javascript ideas you should easily be able to handle downgrading based on the browser environment. Why do you need these flags? – James Black Jul 18 '13 at 15:49
  • I am not talking about browser feature. But feature flag flipping due to feature rollout in a CI context. – renoirb Jul 18 '13 at 16:05
  • Each of these features should have a function for them. In that function, disable the button when the feature isn't available, and enable it when it is. If they hover over the disabled feature, the same function can ensure the user is informed that the feature will be available in the future. Why make it overly complicated? – James Black Jul 19 '13 at 11:48
  • In the case I had, I actually had to fork behavior based on whether we were to roll out the feature at the moment or not on the UserAcceptation host but still needed to work on the code in our branches. The client infra and deployment stragegy we were using was too unstable for us to use proper branching strategy. Although not ideal, it worked like a charm like it is illustrated for the client. – renoirb Aug 12 '13 at 18:40
  • You could easily have a javascript file that is loaded that adds the not accepted behaviors to the main namespace, so that developers can still test, and once it is done, move that code to the main trunk. Keep it simple. – James Black Aug 12 '13 at 22:52
  • [angular-feature-flags](https://github.com/mjt01/angular-feature-flags) is a simple example to show/hide feature via directive, and you can keep all the feature flags into a single JSON resource. – shawnzhu Nov 24 '14 at 19:22

0 Answers0