Why do we prefer using $q in angular instead of $http

Question

I am currently using $q service from angular to make API calls like this:

var deferred = $q.defer();
$http.get(config.apiHost + details.url)
    .success(function (data) {
        deferred.resolve(data);
    }).error(function (msg) {
        deferred.reject(msg);
    });
return deferred.promise;

but we can also use this approach also without using $q:

return $http.get(config.apiHost + details.url)
    .success(function (data) {
        return data;
    }).error(function (msg) {
        return msg;
    });

and as $http itself returns the promise, I can also use more simplified approach:

$http.get(config.apiHost + 'posts')
        .success(function (data) {
            console.log(data)
        }).error(function (msg) {
            console.log(msg);
        });

So what is the difference between all these specially between $q and $http, as both returns promise and both are async ? Does angular provides some additional functionality with $q ? I am not able to find any good answer.

Answer 1

$http uses $q, the first example is redundant, and so is the second. You just need to return the promise that $http.get returns:

return $http.get(config.apiHost + details.url);

The above is the same as your first piece of code.

In addition, return msg is not the same as deferred.reject(msg). The equivalent would be throw msg or return $q.reject(msg)

Another thing to note is that success and error are non-standard, you want to use then and catch.

Answer 2

$q is mainly only used for compatibility with libraries that don't support promises by default and when you can't rely on a native implementation of Promise (for example - in older browsers like IE9). There's no reason (for you) to use it otherwise. An example would if you wanted to make a promise-based $timeout. $http itself uses $q under the hood for these exact reasons.

Unlike what other (since deleted) answers have suggested, you do not need to use $q in order to "store" the result of the $http promise. I would not recommend storing the promise at all (as this tends to lead to spaghetti code), but if you must absolutely do this, you can just store the resultant promise from $http; promises only ever execute once.

Any functions passed to then after a promise has resolved/rejected will be resolved on the next tick, without re-invoking the original action that created the promise in the first place - IOW, the result of the promise is memoized within that object.

Also note that promises chain, which is abit out of scope for this answer, but it essentially means that the following pieces of code are equivalent

function legacyGet() {
  const deferred = $q.defer()
  $http.get('http://www.google.com')
    .then((response) => deferred.resolve(Object.assign(response, {foo: bar}))
    .catch((error) => deferred.reject(error))
  return deferred.defer
}

function modernGet() {
  return $http.get('http://www.google.com')
    .then((response) => Object.assign(response, {foo: bar}))
}

To summarise: Your title is wrong. We don't prefer using $q, we only use it sparingly. Prefer to use an ES6 Promise unless you need to support browsers that don't have it and you can't use a polyfill.

Answer 3

In angular mostly all the services returns promises only, but there are some instances where you would like to create your own deferred object using $q.

Case 1

When you are using a library which does not support promise or you have created your own function and want to return a promise.

Case 2

When you are using any construct which by default returns a promise but you want to return a separate promise based on some on some condition.

Example: In angular $http returns a promise only but now if you want that if the response of this promise contains a particular value then only you want to return resolved else return failure then you need to create your own deffered object and need to resolve or fail it based on the value returned by $http response.