In today’s fast-paced, feature-driven markets, it’s important to continuously deliver value and receive feedback on features quickly and continuously. Partnering with end users to get early versions of features vetted out is valuable.
Are you planning to continuously integrate features into your application while they’re under development? You probably have a few questions, such as:
How can you toggle features to hide, disable, or enable features at run-time?
How can you revert a change deployed to production without rolling back your release?
How can you present users with variants of a feature, to determine which one performs better?
We might want some features to be available to developers only and we might have a set of beta users who we want to expose the feature to. In this case we need a framework which grows above the *ngIf from Angular.
The importance of such framework is that when we want to remove the flighting and make it available to general public it should not be a hurdle to do.
For this we would have to create a backend and a frontend that would be readily used. In this I would be discussing on the UI part of this framework.
For backend, I would be using Azure App Configuration exposed over an api which would be called from UI to get the feature information. I will cover that in a separate post.
Traditionally you can use the *ngIf or [hidden] or even redirections. However the key is to expose a directive and use a Angular Service for reusability. Plus we need to efficient enough to add a caching layer so that we don’t keep on calling the API and save some network cost.
First we create a model class on taking the inputs and the kind of flighting we want to have -
Models required
Now we would be requiring a Angular Service that uses these models and decides the flighting
Service
In this injectable service, we are essentially using calling an external service (refer the backend POST) and we are storing the flighting information in cache (session storage). The code is available in github.
Now we create a directive to use this service.
Directive
Once we have these three in place we are good to know. You can keep them in a shared angular module and export the directive and the service.
The good point here is that unlike traditional way, you don’t need to inject the service in every component you wish to use. You can just create a model and use the directive directly in the html and the binding would be handled by Angular.
Implementation in code-
Now lets say you have a component in UI that you wish to feature flight to some users. For other’s that option should not appear, in that case you can create a model like explained below.
Declare a variable in your TS file
And then populate the model in ngInit
Here you are mentioning that if the feature is not flighting then the attribute this is applied on should be hidden. The key is passed to the feature type and the value is the user email. In case you wish to expose it per user you can follow this way. But in case there is a common attribute let’s say country code and you wish to expose a feature to an entire country then you need to pass the feature key would become by country code and you need to handle the same in the directive.
And in the html you would need to add this attribute on the element you want to toggle.
And that’s it.
Once you build the reusable component (service, directive and models), you can use the code extensively by just proving a model input and binding the html element with the model.
There can we different use cases, such as
Hide if flighted
Show if flighted
Redirect to some unauthorized page if flighted.
All of such conditions can be a part of the service and then you can use the feature by just toggling the model across components.
I would create a separate post on the API service that would fetch the flighting inputs.
Do give me a thumbs up in case you find this useful.
Here are the link to the code base -
https://github.com/5-k/feature-flighting-angular
Cheers