When should I use then() method and what is the difference between then(), success(), error() methods ?
Other than the success un-wraps the response into four properties in callback, where as then does not. There is subtle difference between the two.
The then function returns a promise that is resolved by the return values for it's success and error callbacks.
The success and error too return a promise but it is always resolved with the return data of $http call itself. This is how the implementation for success in angular source looks like:
promise.success = function(fn) {
promise.then(function(response) {
fn(response.data, response.status, response.headers, config);
});
return promise;
};
To understand how it can affect our implementation, consider an example where we retrieve whether user exists based on email id. The http implementation below tries to retrieve the user based on userid.
$scope.userExists= $http.get('/users?email='test#abc.com'')
.then(function(response) {
if(response.data) return true; //data is the data returned from server
else return false;
});
The promise assigned to userExists resolves to either true or false;
Whereas if we use success
$scope.userExists= $http.get('/users?email='test#abc.com'')
.success(function(data) { //data is the response user data from server.
if(data) return true; // These statements have no affect.
else return false;
});
The promise assigned to userExists resolves either a user object or null, because success returns the original $http.get promise.
Bottom line is use then if you want to do some type of promise chaining.
then() method fires in both the success and failure cases. The then() method takes two arguments a success and an error callback which will be called with a response object.
Related
In all my services, I'm just invoking REST services and returning the promises to the controllers. All the error's are handled at controllers using catch like below,
MyService.getData(url).then(getDataSuccess).catch(exception.catcher('Contact Admin : '));
My question here is, Since the real $http calls will be made at service, should I have to write catchers in service or catching in controller is fine?,
Scenario 1:
function getData(url){
return $http.get(url);
}
Scenario 2: (Nested calls to make combined results)
function getOtherData(url){
var defer = $q.defer();
$http.get(url).then(
function(response){
$http.get(nextService).then(
function(res){
defer.resolve('combined data');
}
)
}
);
return defer.promise;
}
Both the service method is not handling any errors. Instead it just returns the promise. Will there be any situation where this kind of exception handling will get failed?
Note: I have created decorators for handling javascript,angular errors and route errors separately. This question is particularly about $http service errors.
Yes what you have can fail triggering your catch because you have no reject().
You are using an anti-pattern creating your own promise and not chaining the nested request properly. Neither of those request rejections will be returned anywhere.
To be able to chain these get rid of the $q.defer() and do:
function getOtherData(url) {
// return beginning of promise chain
return $http.get(url).then(function (response) {
// return next promise
return $http.get(nextService).then(function (res) {
// combine and return the data
return {
d1 : response.data,
d2 : res.data
};
});
});
}
Now walk through the scenarios and each part of chain is intact.
Think of the chain as each then needs a return until the end of the chain
Scenario 2: (Nested calls to make combined results)
Failed Scenario
function getOtherData(url){
var defer = $q.defer();
$http.get(url).then(
function(response){
$http.get(nextService).then(
function(res){
defer.resolve('combined data');
}
)
}
);
return defer.promise;
}
This scenario will fail if the first $http.get has an error. The promise will hang and never get resolved. This is why we recommend avoiding using $q.defer to create promises from services that already return promises.
Instead return data and chain promises.
function getOtherData(url) {
var promise = $http.get(url);
var derivedPromise =
promise.then ( function (response) {
var data = response.data;
var nextPromise = $http.get(nextService);
var derivedNext = nextPromise.then(function(response) {
//return for chaining
return response.data;
});
//return composite for chaining
return $q.all([data, derivedNext]);
});
return derivedPromise;
};
The getOtherData(url) promise will be fulfilled with an array with the data from the two XHRs or it will be rejected with the first error response.
It is possible to create chains of any length and since a promise can be resolved with another promise (which will defer its resolution further), it is possible to pause/defer resolution of the promises at any point in the chain. This makes it possible to implement powerful APIs.1
Chaining error handlers
In an error handler, to convert a rejected resolution to a fulfilled resolution return data. To chain a rejection, throw the error.
For example:
promise = http.get(someUrl);
derivedPromise = promise.catch(function(errorResponse) {
if (fixable) {
fixedPromise = $http.get(fixedUrl);
//return to convert
return fixedPromise;
} else {
//throw to chain rejection
throw errorResponse;
}
};
By chaining error handlers, errors can be handled both by the service and the client of the service.
This makes it possible to implement powerful APIs like $http's response interceptors.1
Building on #georgeawg's answer, if you want to return multiple sets of data then you don't need nested calls.
function getOtherData(url) {
var promise1 = $http.get(url).then ( function (response) {
return response.data;
});
var promise2 = $http.get(nextService).then(function(response) {
return response.data;
});
return $q.all([promise1, promise2]);
};
Now the caller gets a promise that resolves to a list of the 2 data items (or is rejected if either request fails). The only real difference is that both requests are issues in parallel.
This generalises easily to a situation where you could have a list of urls, fetch them all in parallel and get an array of the response.data items.
Because you get back only a single promise that resolves to an array of data you can handle the result in the controller, but you only need one error handler.
MyService.getOtherData(url)
.then(getDataSuccess)
.catch(exception.catcher('Contact Admin : '));
Although the original question doesn't specify, it might be the case that the second url depends on the result from the first. You can handle that case here as well if you remember that you can call .then() multiple times on the same promise:
function getOtherData(url) {
var promise1 = $http.get(url).then ( function (response) {
return response.data;
});
var promise2 = promise1.then(function(response) {
// compute nextService from response.data here...
var nextService = foo(response.data);
return $http.get(nextService).then(function(response) {
return response.data;
});
});
return $q.all([promise1, promise2]);
};
How is result passed from the $http object to the unnamed function that is executed on success?
$http
.success(function (result) {
...
})
I know that the result is passed via any variable name that i put into the function. It is typically called result. But how is this done? It seems like wizardry to me.
I would expect to have to write something like:
$http
.success(function (result=$http.result) {
...
})
You have to study how both Javascript Function Paramters and Promises work.
The code that you pasted comes, I Think, from some AngularJS Application.
If my assumption is correct, $http is a service and doesn't have anyone success method.
The success method is present on $http methods:
//get, post, ecc...
$http.get(...).success()
By the way:
Javascript doesn't provide any way to match parameters, their order is always the order provided by the callee and the names that you use is just for you (Don't confuse with the IOC that the DependencyInjection in AngularJS does). EXAMPLE 1
function loggerCase1(log1, log2, log3, log4) {
console.log('loggerCase1 => param-1:', log1);
console.log('loggerCase1 => param-2:', log2);
console.log('loggerCase1 => param-3:', log3);
console.log('loggerCase1 => param-4:', log4);
console.log('---------------------');
};
function loggerCase2(log4, log2, log1, log3) {
console.log('loggerCase2 => param-1:', log4);
console.log('loggerCase2 => param-2:', log2);
console.log('loggerCase2 => param-3:', log1);
console.log('loggerCase2 => param-4:', log3);
console.log('---------------------');
};
function loggerCaseN() {
for(var i = 0; i < arguments.length; i++) {
console.log('loggerCaseN => param-' + (i + 1) + ': ', arguments[i]);
}
console.log('---------------------');
};
var logs = ['log1', 'log2', 'log3', 'log4'];
loggerCase1.apply(this, logs);
loggerCase2.apply(this, logs);
loggerCaseN.apply(this, logs);
If it's all clear about function parameters behaviour in javascript... you will know that isn't possibile to say give me the first as the second or something like that, also, the example that you pasted seems similar to default parameters (implemented in ES6, aka Javascript Harmony).
Let's go to the point 2:
In a simple promise chain (find on google or see the link above) you can pass a result to the next callback using return. EXAMPLE2
angular
.module('promisechainging', [])
.run(function($q) {
$q
.when('Hello World')
.then(function(greetings) {
console.log('ring 1', greetings);
return greetings;
})
.then(function(salut) {
console.log('ring 2', salut);
return salut;
})
.then(function(ciao) {
console.log('ring 3', ciao);
return { message: ciao };
})
.then(function(result) {
console.log('ring 4', result.message);
return result;
})
.catch(function(error) {
console.log('THIS LOG NEVER HAPPENS BECAUSE THERE AREN\'T REJECTED PROMISES');
return $q.reject(error);
})
.finally(function() {
console.log('We Are At The END');
})
;
})
;
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.23/angular.min.js"></script>
<div ng-app="promisechainging"></div>
Basically is not important how parameters are named!
Angular is using the promise mechanism which basically returns an object that let you know when the result is available or an error has been thrown.
When the ajax call returns, angular is calling the promise and providing the result as a parameter.
It's just like calling a regular function.
$http allows you to perform async network operations and returns a promise object (you can read more about promises in Angular here).
The success and error methods were used to declare callbacks to what happens when the promise is resolved (when the request was successfully completed) or rejected (when there was an error at processing the request). I used the past tense since they are now deprecated and the desired way to handle these is using the then method of the promise object.
// Simple GET request example:
$http({
method: 'GET',
url: '/someUrl'
}).then(function successCallback(response) {
// this callback will be called asynchronously
// when the response is available
}, function errorCallback(response) {
// called asynchronously if an error occurs
// or server returns response with an error status.
});
Basically, the syntax is pretty much the same - the successCallbackFunction has the same signature as the method you were passing in the success method of your example.
But this is only the method signature. Your callback function parameters can be called however you want (result, data etc). All you have to keep in mind is that the first parameter in your callback function is going to be the data returned by your request.
$http
.success(function (result) {
...
})
$http will return a Promise Object which is nothing but a Javascript Object with success and different other functions.
So the statement immediately becomes like below as $http is evaluated,
(Promise Object)
.success(function (result) {
...
})
The success function of promise will save this anonymous function to be called once the promise is resolved. We can manually resolve promises, but I guess http will do this for you here.
Once http request(AJAX) is successful angular will tell this Promise object to run this success function by resolving the Promise, somewhat like:
suceess: function(responseData){ //success of AJAX
resolve(responseData); //this will pass the result to promise
}
Once resolve is called promise object has the result with it, it will then call the success function you passed initially with this value of result.
PS: This is a rough idea, I ave to look into Angular source to see their actual implementation.
Javascript functions are also class objects.
When $http completes it will call either the success or fail function - they are objects so they can be passed around. When it does, it will provide the parameters.
How do I reject or fail a successful $http.get() promise? When I receive the data, I run a validator against it and if the data doesn't have required properties I want to reject the request. I know I can do after the promise is resolved, but it seems like a good idea to intercept errors as soon as possible.
I'm familiar with the benefits of $q, but really want to continue using $http.
You can reject any promise by returning $q.reject("reason") to the next chained .then.
Same with $http, which returns a promise - this could be as follows:
return $http.get("data.json").then(function(response){
if (response.data === "something I don't like") {
return $q.reject("bad data");
}
return response.data;
}
This could simply be done within a service, which pre-handles the response with the .then as specified above, and returns some data - or a rejection.
If you want to do this at an app-level, you could use $http interceptors - this is just a service that provides functions to handle $http requests and responses, and allows you to intercept a response and return either a response - same or modified - or a promise of the response, including a rejection.
.factory("fooInterceptor", function($q){
return {
response: function(response){
if (response.data === "something I don't like") {
return $q.reject("bad data");
}
return response;
}
}
});
Same idea as above - except, at a different level.
Note, that to register an interceptor, you need to do this within a .config:
$httpProvider.interceptors.push("fooInterceptor");
You can use AngularJS interceptors. But you still need to use $q in them because $http uses $q.
Here is a useful article about interceptors.
I'm a bit confused how to chain promises in AngularJS. I have a $resource implementation... This is some simplified code to get my point:
myResource
.save({ id: 123 })
.$promise
.then(function(data) {
// redirect to root on success
$location.url("/");
})
.catch(function() {
console.log("Failed");
})
.finally(function() {
// reenable form
$scope.enabled = true;
})
What I'm confused about is whether my .catch() function will be called when my resource will fail saving or will it only catch errors that would originate in .then() function or maybe both?
When chaining these how can I have a single .catch (before .finally) that would catch all errors of calls that happened in the chain proceeding it?
Note: I'm aware I could provide the success and error functions in .save function but I have other parts to handle as well.
First of all, read the docs of Angular's implementation of promises.
Promises can be resolved in two ways - either successful (the resolve method) or not (the reject method).
When resource could not be saved (i.e. server did not respond with 2XX status), then your catch method will be called, as the promise will be rejected.
Also please note, that your catch handler should reject the promise for next possible handlers. When you return non-rejected value from your catch method, it is assumed that the error has been handled and the promise can call subsequent then methods, if any. Therefore, if there is any possibility that the promise is used somewhere else, your code should look like this:
// inject $q
myResource
.save({ id: 123 })
.$promise
.then(function(data) {
// redirect to root on success
$location.url("/");
})
.catch(function() {
console.log("Failed");
return $q.reject();
})
.finally(function() {
// reenable form
$scope.enabled = true;
})
Also notice that you made a typo in the then method - you wrote "ulr" instead of "url".
I have a unittest where a service returns a promise. Sometimes that service might make a $http request, sometimes it won't (It implements a cache of sorts). In either case, it resolves the promise, but only in $httpBackend.flush() does it actually get around to making the callbacks. How can I cause the promises that are resolved to actually call the functions in the .then() like flush() does.
This one works just fine
resolved = jasmine.createSpy();
rejected = jasmine.createSpy();
employeeEventService.loadSchedules()
.then(resolved, rejected);
$httpBackend.flush(); // This causes the promise to resolve/reject
expect(resolved).toHaveBeenCalled();
expect(rejected).not.toHaveBeenCalled();
This one doesn't work because I can't call flush() (since the service never called $http)
resolved = jasmine.createSpy();
rejected = jasmine.createSpy();
employeeEventService.loadSchedules()
.then(resolved, rejected);
//$httpBackend.flush(); // Can't call this because this call is "cached"
expect(resolved).toHaveBeenCalled();
expect(rejected).not.toHaveBeenCalled();
Service code:
if(loaded.startOn <= params.startOn && loaded.endOn >= params.endOn
&& new Date() - lastFetch < 60000) {
deferred.resolve(loaded.schedules);
} else {
service.loading +=1;
config = {params: params, timeout:30*1000};
$http.get('/api/employee-schedules/', config)
.then(function(response) {
...
process the json response
...
deferred.resolve(loaded.schedules);
}, function(reason, status) {
$log.error("Failed to get schedules", reason, status);
deferred.reject(reason, status);
})
.finally(function() {
service.loading -=1;
});
}
return deferred.promise;
All promises, regardless of what pattern they are in, are resolved when you call $scope.$digest();
You're using a promise antipattern in your service, which is why you're encountering these issues. Instead, try this pattern:
function loadSchedules () {
return (cachedSchedules) ? $q.when(cachedSchedules) : asyncHTTPStuffs();
}
(Thanks to Benjamin Gruenbaum)
This way, you can return a thenable object, regardless of cache status, while not needing to call $httpBackend.flush() if you know the data is cached.