What is the cleanest way to intercept certain routes? - angularjs

Question

I am working with interceptors, and they intercept all requests but I have certain routes where I don't want to interfere with the request/response
app.service('WizardService', ['$http', function($http) {
var base_url = '/api';
var service = {};
service.postStep1 = function (){
return $http.post(base_url+'/step-1');
};
service.postStep2 = function (data){
return $http.post(base_url+'/step-2', data);
};
service.postStep3 = function (data){
return $http.post(base_url+'/step-3', data);
};
return service;
}]);
For step 1 and 2, I want to use InteceptorA and Step 3 I want to use InterceptorB. What is the cleanest way to do this?

Answer 1

What Cloves answered is good but if there are multiple routes then it will be hard to assign multiple if conditions based on the URL. Also, if the URL changes, you need to modify in the interceptor as well.
I guess the cleanest way of achieving this is the config. Let's start with your service:
app.service('WizardService', ['$http', function($http) {
var base_url = '/api';
var service = {};
service.postStep1 = function (){
return $http.post(base_url + '/step-3', null, {interceptMe: 'A'});
};
service.postStep2 = function (data){
return $http.post(base_url + '/step-2', null, {interceptMe: 'A'});
};
service.postStep3 = function (data){
return $http.post(base_url + '/step-3', null, {interceptMe: 'B'});
};
service.postStep4 = function (data) {
// no interception
return $http.post(base_url + '/step-3');
};
return service;
}]);
Now, register the interceptor (I'm just showing you the main logic of interceptor):
$httpProvider.interceptors.push(['$rootScope', function($rootScope, $q) {
return {
'request': function (config) {
if (config.interceptMe) {
if (config.interceptMe === 'A') {
// do something for interceptor type A
} else if (config.interceptMe === 'B') {
// do for type B
}
}
return config;
}
}
});

Answer 2

Implement a single interceptor, as shown in the documentation for the $http service.
If you need to intercept requests, in the 'requests' callback, inspect the config.url and use something like regex matching. Example:
// register the interceptor as a service
$provide.factory('myInterceptor', function() {
return {
'request': function(config) {
if (/step-1$/.test(config.url)) doSomething1();
if (/step-2$/.test(config.url)) doSomething2();
if (/step-3$/.test(config.url)) doSomething3();
return config;
}
}
}

Answer 3

First off, there's nothing in the $http service and its use of the $httpProvider.interceptors property to help accomplish what you're looking for.
Referring to v1.5.6 source.
.interceptors is a plan array (line 375):
var interceptorFactories = this.interceptors = [];
And they're ultimately just pushed (or unshifted) into the promise chain, depending on whether it's a request or response.
Line 986:
// apply interceptors
forEach(reversedInterceptors, function(interceptor) {
if (interceptor.request || interceptor.requestError) {
chain.unshift(interceptor.request, interceptor.requestError);
}
if (interceptor.response || interceptor.responseError) {
chain.push(interceptor.response, interceptor.responseError);
}
});
So, other than rolling your own alternative to the $http service (not something I'd recommend in this case), you'll have to work within the confines of what you can do within a http interceptor itself. In other words, the interceptor (or interceptors) will have to manage filtering routes itself.
I see 3 slightly different ways you could go about this.
A single interceptor to act as a 'marshal' to call logic based on the route.
Multiple interceptors, each with their own route filtering logic.
Multiple interceptors with configured / injected rout filtering logic.
Which of these methods works best for you will depend on a few factors, like:
Quantity of interceptors
Complexity of route filtering (your example could be a simplified one)
Likelihood that filtering rules will change independently of interceptor logic
A note on singletons
Keep in mind that services are singletons. They're created once, and re-used. Per Angular doco:
Each component dependent on a service gets a reference to the single instance generated by the service factory.
So, while there's undoubtedly some overhead in $http going through a long promise chain if you've got multiple interceptors registered, it's not as taxing as it might first seem. That said, you've mentioned in comments that you might be registering as many as 100 interceptors, and I cannot comment on the specific performance impact that may or may not have.
1 - Single Interceptor
Cloves answer already provided an example for this, as did Shashank's. Something like this:
function SingleInterceptor() {
var service = {
request: request
};
return service;
function request(config) {
if (config.url === base_url + '/step-1') {
step1Logic();
}
if (config.url === base_url + '/step-2') {
step2Logic();
}
// etc...
return config;
}
}
This is neat and simple if you've not got a lot of different interceptor logic to deal with, but could become a bit clumsy to maintain in higher volumes.
2 - Multiple Interceptors (with their own filtering)
Each interceptor has its own logic for determining whether the route applies. Like:
function InterceptorStep1() {
var service = {
request: request
};
return service;
function request(config) {
if (config.url === base_url + '/step-1') {
// Step 1 logic here
}
return config;
}
}
function InterceptorStep1() {
var service = {
request: request
};
return service;
function request(config) {
if (config.url === base_url + '/step-2') {
// Step 2 logic here
}
return config;
}
}
This would be more maintainable in high volumes, but becomes awkward if you want to start changing the filtering rules, or the interceptors don't have an obvious one-to-one mapping with URL's. Hypothesising here, maybe they're not all as obvious as "Step 1", "Step 2", etc.
3 - Multiple Interceptors (config based filtering)
Similar to #2, but separate the route filtering logic from the interceptors themselves by using a provider for each.
function InterceptorB(filterUrl) {
var service = {
request: request
};
return service;
function request(config) {
if (!filterUrl || filterUrl(config.url)) {
// Logic here
}
return config;
}
}
angular
.module('app')
.provider('InterceptorB', function InterceptorBProvider() {
var filterUrlInner;
this.setFilterUrlCallback = function (fn) {
filterUrlInner = fn;
};
this.$get = [function InterceptorBFactory($log) {
return new InterceptorB(filterUrlInner);
}];
});
There's more work in getting this one set up in the first place, but is in my view the most flexible and easily maintained once you've got more than just a few interceptors.