In these days you want to try ideas fast to see if they stick. You want to be able to split test to ideas and see what performs the best. If you for some reason want to disable or enable a feature you would want to do that instantaneously without having to redeploy the application. Sounds good, but how do you do this? One word: feature toggling.

Feature toggling is where you are inserting toggle points in your code, which is basically conditionals, that check if some flag is enabled. If it is the feature is enabled and if not the feature is disabled. This enables advantages such as experimenting with split tests, open up features for test users, release toggles used in implementing continuous delivery as well as permanent maintenance toggles for disabling certain features eg. if the server is running out of resources.

How to implement feature toggling in Angular

The above benefits of feature toggling can be achieved in Angular by creating a service for encapsulating the feature toggle logic. You can find a demo app of feature toggling with Angular on my Github.

A new Angular app is setup using:

ng new angular-feature-toggling-demo

Two feature components are created using:

ng g c feature-a

ng g c feature-b

This should create two components: one named feature-a and one named feature-b.

Next, a feature toggle service is created in app/core of the application workspace:

The feature toggle service has a method, isFeatureEnabled, to check if a feature is enabled. This method will either calculate a percent to determine if a feature should be shown or work with a plain boolean. This enables for canary releases as well as split testing. A third party library called seedrandom is installed for ensuring that the current user is seing the same features on every load. Seedrandom can be installed with:

npm i seedrandom

The user-id should be fetched from the  authentication endpoint and used here instead of the default user-id.

The features this service is working with is fetched from the assets folder as a feature-config.json file:

This defines a new feature called “killer-feature” that is shown to 50% of the users. This enables us to try out a new feature on a subset of the users while analyzing how it performs compared to existing features.

Next, the feature-config.json is gonna be loaded on app initialization using the APP_INITIALIZER provider:

An app initializer method is used to run async code before the app loads. It should return a promise and the app will start loading once this promise is installed. Bear in mind that this creates extra loading time for the app so you might also want to look into creating a loading spinner for that.

The app init service is set up in app.module.ts like this:

Lastly, this enables us to feature toggle our feature-a and feature-b components. We are gonna use the feature toggle service to check if the killer-feature is enabled and show a specific component if it is:

Bonus tip

Now that you have the basic feature toggling enablers in place you can mix this with services like Google Analytics and Hotjar to get analytics and records of the user experience of the features you are evaluating.

Conclusion

We looked at the benefits of feature toggling and how to use feature toggling for enabling release toggles, split testing and permanent toggles.

We went through how to implement feature toggling in an Angular app for split testing two features using a percent throttle.