This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
Remove responseInterceptors collection from $httpProvider for 1.3 #7266
Comments
caitp
added a commit
to caitp/angular.js
that referenced
this issue
Apr 27, 2014
Code cleanup! response interceptors have been deprecated for some time, and it is confusing to have
two APIs, one of which is slightly "hidden" and hard to see, which perform the same task. The newer
API is a bit cleaner and more visible, so this is naturally preferred.
BREAKING CHANGE:
Previously, it was possible to register a response interceptor like so:
// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) {
return function(promise) {
return promise.then(function(response) {
// do something on success
return response;
}, function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
});
}
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Now, one must use the newer API introduced in v1.1.4 (4ae4681), like so:
$provide.factory('myHttpInterceptor', function($q) {
return {
response: function(response) {
// do something on success
return response;
},
responseError: function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
}
};
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Closes angular#7266
caitp
added a commit
to caitp/angular.js
that referenced
this issue
Apr 27, 2014
Code cleanup! response interceptors have been deprecated for some time, and it is confusing to have
two APIs, one of which is slightly "hidden" and hard to see, which perform the same task. The newer
API is a bit cleaner and more visible, so this is naturally preferred.
BREAKING CHANGE:
Previously, it was possible to register a response interceptor like so:
// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) {
return function(promise) {
return promise.then(function(response) {
// do something on success
return response;
}, function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
});
}
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Now, one must use the newer API introduced in v1.1.4 (4ae4681), like so:
$provide.factory('myHttpInterceptor', function($q) {
return {
response: function(response) {
// do something on success
return response;
},
responseError: function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
}
};
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Closes angular#7266
caitp
added a commit
to caitp/angular.js
that referenced
this issue
Apr 27, 2014
Code cleanup! response interceptors have been deprecated for some time, and it is confusing to have
two APIs, one of which is slightly "hidden" and hard to see, which perform the same task. The newer
API is a bit cleaner and more visible, so this is naturally preferred.
BREAKING CHANGE:
Previously, it was possible to register a response interceptor like so:
// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) {
return function(promise) {
return promise.then(function(response) {
// do something on success
return response;
}, function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
});
}
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Now, one must use the newer API introduced in v1.1.4 (4ae4681), like so:
$provide.factory('myHttpInterceptor', function($q) {
return {
response: function(response) {
// do something on success
return response;
},
responseError: function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
}
};
});
$httpProvider.interceptors.push('myHttpInterceptor');
More details on the new interceptors API (which has been around as of v1.1.4) can be found at
https://docs.angularjs.org/api/ng/service/$http#interceptors
Closes angular#7266
stickel
pushed a commit
to stickel/angular.js
that referenced
this issue
May 1, 2014
Code cleanup! response interceptors have been deprecated for some time, and it is confusing to have
two APIs, one of which is slightly "hidden" and hard to see, which perform the same task. The newer
API is a bit cleaner and more visible, so this is naturally preferred.
BREAKING CHANGE:
Previously, it was possible to register a response interceptor like so:
// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, dependency2) {
return function(promise) {
return promise.then(function(response) {
// do something on success
return response;
}, function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
});
}
});
$httpProvider.responseInterceptors.push('myHttpInterceptor');
Now, one must use the newer API introduced in v1.1.4 (4ae4681), like so:
$provide.factory('myHttpInterceptor', function($q) {
return {
response: function(response) {
// do something on success
return response;
},
responseError: function(response) {
// do something on error
if (canRecover(response)) {
return responseOrNewPromise
}
return $q.reject(response);
}
};
});
$httpProvider.interceptors.push('myHttpInterceptor');
More details on the new interceptors API (which has been around as of v1.1.4) can be found at
https://docs.angularjs.org/api/ng/service/$http#interceptors
Closes angular#7266
Closes angular#7267
chrisghost
added a commit
to chrisghost/angularjs-spinner
that referenced
this issue
May 6, 2014
Angular 1.3.0 removes $httpProvider.responseInterceptors (source : angular/angular.js#7266) This may not be compatible with angular < 1.1.4 (before caitp/angular.js@4ae46814)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
To be honest, I didn't even know we had a responseInterceptors collection to begin with. I only found out this existed because of a question on IRC.
But basically, it's super awkward to have 2 apis which essentially do an equivalent thing, with one being more obvious in the docs than the other. And getting rid of the responseInterceptors collection means there are a few lines of code and docs that can be removed, so this is a good thing.
I think it's worth dropping it for 1.3, in the name of clean API and simplicity.
The text was updated successfully, but these errors were encountered: