Permalink
4 comments
on commit
sign in to comment.
Browse files
feat($http): remove deprecated callback methods: `success()/error()`
Closes #15157 BREAKING CHANGE: `$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed. You can use the standard `then()`/`catch()` promise methods instead, but note that the method signatures and return values are different. `success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either `then(null, fn)` or `catch(fn)`. Before: ```js $http(...). success(function onSuccess(data, status, headers, config) { // Handle success ... }). error(function onError(data, status, headers, config) { // Handle error ... }); ``` After: ```js $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }, function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); // or $http(...). then(function onSuccess(response) { // Handle success var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }). catch(function onError(response) { // Handle error var data = response.data; var status = response.status; var statusText = response.statusText; var headers = response.headers; var config = response.config; ... }); ``` **Note:** There is a subtle difference between the variations showed above. When using `$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the `onError()` callback will only handle errors/rejections produced by the `$http()` call. If the `onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
- Loading branch information
Showing
with
95 additions
and 331 deletions.
- +0 −45 docs/content/error/$http/legacy.ngdoc
- +0 −60 src/ng/http.js
- +2 −2 src/ng/sce.js
- +93 −224 test/ng/httpSpec.js
Oops, something went wrong.
This comment has been minimized.
This appears to be a completely unnecessary breaking change.
This comment has been minimized.
It is standard practice to eventually remove deplrecated APIs after some time. It prevents people from using these inferior APIs, removes unnecessary code and reduces maintainance cost.
This particular change has minimal impact for the last two points, but significantly contributes to the first one.
This comment has been minimized.
It appears to have been unnecessary. And Narretz even said "We rarely removed deprecated features." The obvious reason to minimize breaking changes is to ... not break the applications which use the API, when there is no compelling reason to do so. Something to think about.
This comment has been minimized.
Hm...we have removed several deprecated features. (Off the top of my head: Global controllers, auto-unwrapping of promises,
angular.xyz()helpers (e.g.lowercase/uppercase),ngScenario, severalngTouchservices/directives,$cookieStore,$compileProvider.preAssignBindingsEnabled(), etc.)As mentioned, it is standard practice. Especially in this case, I feel strongly that removing the old APIs was benefitial to users. They had been deprecated for a while (so people had plenty of time to plan their migration), the migration was easy enough and the old APIs had subtle caveats that could catch people off-guard (especially with the standardization of Promises).
I'll try to think about it, but can't promise anything😛 ☮️
(Agreeing on disagreeing is also fine, btw😉 )