A Guide to Getting Started Quickly With AngularJS Feature Flags

Want to become an expert in feature flagging in AngularJS? Perfect. You’re in the right place. Because today we’re going to do just that—go through the ins and outs of feature flagging in AngularJS. In this article, we’re going to cover what feature flagging is at a general level, what that means for software and delivery, and why you should care. Then we’ll look at different ways that you can implement feature flags at an architectural level and their pros and cons. Following this, we’ll briefly look at how we can implement feature flags in AngularJS and their pros and cons before walking step-by-step through how to get your AngularJS app running with feature flags. Ready to become an expert? Good! Let’s get to it.

Before we get to the implementation, let’s take a moment to address why feature flags are a must-have in a developers toolkit. Feature flagging supports both product development processes and also the delivery of software. So, what are feature flags? Simply put: feature flagging is a development practice that allows the toggling of features. You can use feature flags to switch a feature on or off completely. Or we can use them to phase in a feature equally across the world—or even using some other factor, such as region or demographic. But why is this useful? While there are many answers to this, let’s look at two important ones...

For instance, let’s consider teams that practice continuous integration, continuous delivery, and continuous deployment. Teams using these delivery practices aim to make very small commits frequently into a single branch. These teams do so to keep changes flowing into production to reduce risk and speed up delivery. However, sometimes you can't complete all your work in one small commit, so these features are often hidden behind feature flags to allow continuous integration of a codebase without disrupting users. This avoids the difficulties of late integration and the headaches of maintaining an elaborate branching scheme.

Feature flags also help with product teams and experimentation—for instance, companies such as Facebook use regional feature flags to introduce new features. Facebook often rolls out features into countries like Australia first, as they’re a lower-risk country than the US. (Since the US is one of the biggest revenue-generating countries for Facebook, they wouldn't want to start there). Doing so allows Facebook to test their features out on this lower-risk single audience before fully rolling out the application to the rest of the western world if they’re successful.

Okay, so now we’ve looked at some reasons feature flags can be useful. Now let’s take a look at how we can go about implementing them. You can implement feature flags in a range of different ways. Each implementation comes with different speed and trade-offs in capabilities.

• As a flat file—We can implement feature flags in a simple file alongside an application. It's a quick solution, but it's one that's quite inflexible. You'll need to redeploy your app to see the changes, which doesn’t harness the true power of feature flags.

• As environment variables—We can also implement feature flags as environment variables inside our application. This gives us the flexibility of updating our toggles while the application is running, but it still lacks flexibility.

• With an external service—Lastly, feature flags can be managed by a dedicated separate service, giving us the flexibility to turn feature flags on or off in different environments. It also enables other powerful features, such as the ability to view an audit trail of changes.

An external service therefore gives us the most flexibility. However, while building our own external service is an option, it can be very time-consuming. But luckily CloudBees Feature Management.io has done the hard work for us by creating a cloud-based solution that allows us to use feature flags in our own applications easily and quickly. Intrigued by the idea of feature flags and keen to learn more? Then let’s look at how you can get going with feature flags in your AngularJS app.

In order to follow along, you’ll need the following installed on your machine:

• Git

• NodeJS and NPM

Before we begin, let’s just consider the different ways that we could go about implementing feature flagging in our application.

Programmatic implementation would mean to wrap code directly with conditional statements to either run or not run certain code dependent on feature flag configurations. This is potentially the “simpler” option as it allows you a great deal of complexity. However, by writing logic like this, it’s very easy to end up with an application that is messy — using various different patterns throughout the codebase. If we’re not careful our feature flags become hard to remove and difficult to read and understand.

The second option is to encapsulate your feature flag logic into a module. Admittedly this is a slightly more involved solution. However, it ensures that logic related to the feature flag is inside a single module and we're not exposing it elsewhere in the application. The best way to achieve this in AngularJS is with a component and a technique called “transclusion.” If you’re not an Angular guru already, maybe you just thought, “Wait, hold up! What’s transclusion?” Let’s look at that quickly. Transclusion allows a developer to specify a component that wraps another to augment its functionality. A simple example is a tab component—one that embeds content inside a tab but wraps it in a header that, when clicked, hides and shows the inner content. Don’t worry if transclusion doesn’t make total sense at this point. It doesn’t need to. By the end, you’ll have a much better grasp on what transclusion is and how it helps make feature flag code simpler.

First things first: we need an app. (If you already have an app set up, skip to step four.) For this tutorial, we’re going to use the NG6-Angular boilerplate for simplicity. So firstly, let’s clone the repo onto our machine with the following command:

git clone https://github.com/gdi2290/NG6-starter.git

In order to get the app running, you’ll need the dependencies from npm. So go ahead and install those npm packages with the following command. Change directory to the context of your new cloned repo first:

cd NG6-starter;

And install the npm packages.

npm install;

Now that you’ve got your packages installed, let’s check everything is working smoothly now. We can do that by serving the app with the following command:

npm run start

When you run the command, your environment will be running and changes will compile when edits are made. Head over to http://localhost:3000 to ensure your app is running. It should look like this:

Now our app is up and running, we'll need a component to hold our feature flag logic. Let’s do that now. Luckily the NG6 starter kit has a handy command for that. Note: If you’ve got your own application running, you’ll need to make a new Angular component for your particular setup (manually setting up a basic component).

npm run component -- --name featureFlag

When you create this, you’ll see a new “featureFlag” component in your components folder as follows:

Now we’ll want to test that the component is working. We’ll do this by modifying the “hero” component to add our new feature flag component. Head over to client/app/common/hero/hero.html to find the template for the hero component. It should look like this:

<section class="hero">
   <h1>This is the NG6 starter</h1>
   <h3>You can find me inside {{ $ctrl.name }}.html</h3>
</section>

So go ahead and add your feature flag component and embed the new feature flag component onto this page. We can embed a regular AngularJS component by taking its name and converting it into HTML tags, as follows:

<section class="hero">
   <h1>This is the NG6 starter</h1>
   <h3>You can find me inside {{ $ctrl.name }}.html</h3>
   <feature-flag></feature-flag>
</section>

Nice—now you’ve got a feature flag component setup and integrated into a feature page. But we're not done yet as there's one more step. AngularJS won't just allow us to show any component anywhere in an application. Why? Because in larger apps, this can become unmaintainable.

To manage this complexity AngularJS has the notion of “modules”—which are just a group of defined AngularJS bits and pieces like directives, controllers, filters etc. So, we’ll need to add our component to the module that encompasses the hero component. That can be found at:

client/app/components/components.js

This is where the module definition exists.

import angular from 'angular';
import Home from './home/home';
import About from './about/about';

let componentModule = angular.module('app.components', [
Home,
About
])

.name;

export default componentModule;

So go ahead and modify this module definition to include our feature flag component reference. This will now look as follows:

import angular from 'angular';
import Home from './home/home';
import About from './about/about';
import FeatureFlag from './featureFlag/featureFlag';

let componentModule = angular.module('app.components', [
Home,
About,
FeatureFlag
])

.name;

export default componentModule;

Now if you head back over to http://localhost:3000/, you’ll see your running app with your feature flag component.

Awesome, well done so far!

Okay, so now we’re pretty much all done with setup. We’ve got an AngularJS app with a basic component. This is where we’ll start needing CloudBees Feature Management’s help to implement our feature flag functionality. CloudBees Feature Management uses a library called “rox-browser” in order to implement feature flagging capabilities. So we’ll want to go ahead and install that package.

npm i rox-browser --save

In order to consume the CloudBees Feature Management library, we’ll want to create ourselves a configuration file. But before we do that, we’ll need a CloudBees Feature Management account to reference in our file. So let’s do this first. Head over to rollout.io to create yourself an account.

…Okay, you’re back? Awesome. Let’s carry on. Go ahead and create our new configuration file:

touch client/app/featureFlags.js

And add the following code into your newly made file:

import Rox from 'rox-browser';

const featureFlagSettings = {
 showADescription: new Rox.Flag()
};

Rox.register("Production", featureFlagSettings);
Rox.setup("your-rox-key");

export default featureFlagSettings;

This config file is doing quite a lot, so before we continue, let’s break down each of the three parts of the configuration file to understand what’s going on. The config file does a number of things:

• It sets up your app—Using the setup method, Rox will now know which CloudBees Feature Management environment to associate your application with. You can have many environments. For instance, you might have local, staging, and production. So you have control of your feature flags in different environments. It’s good practice to store this type of configuration in environment variables rather than hard-coding it. That way, you can easily change it later.

• Registers your app—Rox will need to know what feature flags and settings it's working with and the name of your environment. In the above example, we’re passing production as our environment name and the object configuration.

• Creates a configuration object—This is where the fun stuff happens. Your Rox object is the configuration of your feature flags. Want a new feature flag? Add a new configuration.

At this point, you might be wondering where you get your app key. Well, you can find your it in the environments page of your CloudBees Feature Management app. Just click "app settings" on the left, and it’s the second tab, “environments,” as below.

With our configuration file set up, we now successfully have a feature flag called “showADescription". However, this code isn’t currently executing just yet. All we’ve done is add the file, but it’s not running as part of our app. It’s a quick job, so let’s do that now. Head over to

 client/app/app.js

and add the following import:

import FeatureFlags from './featureFlags';

Now when your browser refreshes, your “showADescription” feature flag should appear in your CloudBees Feature Management account under the “flags” page.

There it is—your first feature flag configuration!

Okay, so far we have an AngularJS app and a CloudBees Feature Management configuration set up and ready to go. The final thing we need to do is hook up our CloudBees Feature Management feature flag to our component so that the content will either hide or show depending on the value of the feature flag. Originally our component was just showing some example content. But really we want this content to hide and show when we modify our "showADescription" feature flag.

What we’re going to do next is modify our feature flag component to take a configuration string (your feature flag name) and then either hide or show its content based on the feature flag setting. There will be quite a few changes, but don’t worry. We’ll go through what’s happening after each step so you know what’s going on. First head back to our hero template from earlier: client/app/common/hero/hero.html And update the content to include just the following:

<feature-flag flag-name=

In order for this to work, we’ll have to update our component. The component will need to be modified to take a single attribute value, “flagName.” And depending on the state of our feature flag you may need to modify it to show inner content. Let’s update the component by opening up the following file:

client/app/components/featureFlag/featureFlag.component.js

And we'll replace the file contents with the following code:

import template from './featureFlag.html';
import controller from './featureFlag.controller';
import './featureFlag.scss';

let featureFlagComponent = {
bindings: {
  flagName: '@'
},
template,
controller,
transclude: true
};

export default featureFlagComponent;

This component now expects a flag name as a string attribute (that’s what the "@" does). In our case, that’s our feature flag “showADescription.” and the value “transclude” is now set as true. (We’ll come back to what this means in just a second.)

Next, we’ll need to update our controller. So head over to

client/app/components/featureFlag/featureFlag.controller.js

and replace the file contents with the following code:

import featureFlags from '../../featureFlags';

class FeatureFlagController {
    constructor() {
        this.featureFlags = featureFlags;
    }
}

export default FeatureFlagController;

We want to give the template the ability to check if a feature flag is enabled. To do this, we're importing the "featureFlags" configuration file that we created earlier. Then we bind this object to our component (for access later in the template). So far, we’ve got a component that has our CloudBees Feature Management configuration object that we've instantiated with the name of the feature flag to check for. Now, for our last step, we’re going to need to update the template to handle whether to hide and show our content or not. So open up

client/app/components/featureFlag/featureFlag.html

and replace the file contents with the following code:

if="$ctrl.featureFlags[$ctrl.flagName].isEnabled()" ng-transclude>

Phew. We made it.

What we’ve just done is create a transcluding component that wraps another, and depending on the value of the feature flag attribute, it will either hide or show the child content. This means to use this component again in future, all we have to do is two steps:

1. Wrap a piece of content in the feature flag component.

2. Update our feature flag configuration JS file.

For example,

<h1>
   Welcome to my website
</h1>

<feature-flag flag-name="showWebsiteDescription">
   <p> A lovely website description </p>
</feature-flag>

import Rox from 'rox-browser';

const featureFlagSettings = {
showADescription: new Rox.Flag(), showWebsiteDescription: new Rox.Flag()
};

Rox.register("Production", featureFlagSettings);
Rox.setup("your-rox-key");

export default featureFlagSettings;

Okay, so now we have our AngularJS app set up and we have our component that hides and shows functionality. The last piece in the puzzle is to have a go “experimenting” with our new feature flag values to see if the content really does toggle. With CloudBees Feature Management, we implement feature flags using an aptly named feature: “experiments". We’ll want to set one up now so we can test the functioning of our feature flag component. To do this, first head back into your CloudBees Feature Management app and head into the experiments tab. You shouldn’t have any set up right now, but go ahead and click “create experiment” and select “showADescription” as the property for your experiment.

You should now see an experiment set up, with your feature flag set to false. So go ahead and update the dropdown that says "false" to instead say "true" and hit "update audience."

This will publish your feature flag change. Now if you go back to your app at http://localhost:3000/, you should see your content. Yay!

Just to be sure, let’s turn the feature flag back off by toggling to false and updating the audience.

Now, if you refresh your app again, the content is gone.

Feature flags are really powerful. They allow you to get product out into production faster, you can experiment with or modify features, and you'll reduce delivery risk. Something as powerful as feature flagging needs powerful management. And with your new CloudBees Feature Management feature flags, you should be well on your way. Now it’s time to get really advanced and take advantage of the other CloudBees Feature Management features such as split tests, target groups, and advanced experiments You should now be well on your way to becoming a feature flagging expert.