Use Q transparently over $q if available

Q is significantly more featured than $q and is often more useful for that reason. However, working with both Q and $q in the same project (e.g. using Q with $http calls, promise templates), can get very messy. It would be useful for $q to use the full Q library when available, like the behavior of jqlite and jquery.

[ccapndave]

Agreed - there are cases where $q just doesn't cut it and it would be great to get full Q integrated into angular.

[icholy]

Issue is that $q only resolves in the $digest cycle. So Q is not a drop in replacement.

[arhea]

+1. I really need the notify function of q.

[cqr]

@isaacbw @ccapndave @arhea Right now the place where one would hook into Q to make sure resolution would trigger a $digest is private and inaccessible to Angular. What are the specific pieces of functionality that you are missing from Q that are motivating this request?

[arhea]

@chrisrhoden I was looking for the progress api, which is now available. So that one has been checked off the list. Might be behind on this but does angular provide the shortcut methods like .fail .progress? Seems silly but, increases code readability rather than just .then with three anonymous functions.

[cqr]

@arhea you can use .catch instead of .fail. .progress hasn't been implemented yet, but I can write a pull request if that's what you're really looking for.

It's important to bear in mind that it's actually different calling promise.then(callback).catch(error) than promise.then(callback, error), in that the first creates 2 intermediate promises and the second only one. While I don't think that it's likely this will cause problems for you, for instance, the following will resolve to 3:

function addOne(n) {
  return n + 1;
}

function addTwo(n) {
  return n+2;
}

deferred.promise.catch(addTwo).then(addOne);
deferred.reject(0); // above promise resolves to 3

whereas this will resolve to 2:

deferred.promise.then(addOne, addTwo);
deferred.reject(0); // above promise resolves to 2

[arhea]

I am very familiar with promises. However, for supporting IE8 those method names do not work. They are not supported in ES3. That is why I prefer .fail(method) over .catch(method).

I know I can use promise['catch'](method) but, that is worse that just three methods.

Ideally, if angular is going to call it $q then it needs to be api compliant with the real Q library.

[cqr]

...so you think the name should be changed from $q?

On Fri, Oct 18, 2013 at 5:45 PM, Alex Rhea notifications@github.com wrote:

I am very familiar with promises. However, for supporting IE8 those method
names do not work. They are not supported in ES3. That is why I prefer
.fail(method) over .catch(method).

I know I can use promise'catch' but, that is worse that just
three methods.

Ideally, if angular is going to call it $q then it needs to be api
compliant with the real Q library.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1998#issuecomment-26632170
.

chrisrhoden

I agree that it's more than a little misleading to name the library $q if it doesn't emulate at least a good portion of Q's functionality. Q is both a core promise library and a versatile utility kit. Perhaps some effort should be made to expand upon $q's offering, or, in lieu of that, consider renaming $q to something more generic like $promise, or $then?

Are there any objections to adding utility to $q? Are pull requests welcome?

[cqr]

I'm not any more affiliated with the project than you are, I just make an
effort to help clarify what a ticket is requesting and submit pull requests
when possible.

I can tell you that the motivation for $q's relatively limited
functionality is pretty plainly laid out in the documentation - bytes. If
you can add the rest of the functionality that you're requesting with no
additional byte overhead, I am sure that the Angular team would be
receptive. I can further tell you that there's an existing ticket that has
been approved for work regarding a refactoring of $q. I wish that it was
possible to do some monkey patching of Q such that it would serve as a
drop-in replacement for $q, but that's not possible. Maybe you could write
an alternative module that people could opt in to loading on the page which
would decorate $q.

The point I am driving at here is that the request originally made in this
ticket is simply not possible at this time, and its possibility is bound up
in Q giving us an extension point in their API. By asking for more
clarification beyond that, I am trying to see if there's anything
preventing this ticket from being closed. In case you hadn't noticed,
there's a very large amount of tickets, and that has a negative effect on
the ability of the Angular team to address each one.

If what you're saying is that, barring the ability to drop-in the Q library
(which we can't do, because of the way that the Q library is structured),
you want the $q service renamed or a major functional overhaul, you really
ought to file a new ticket. If you know what you want and how to make it,
you can skip straight to a pull request.

That having been said, I recommend this ticket be closed.

On Sat, Oct 19, 2013 at 12:10 PM, Isaac Wagner notifications@github.comwrote:

I agree that it's more than a little misleading to name the library $q if
it doesn't emulate at least a good portion of Q's functionality. Q is both
a core promise library and a versatile utility kit. Perhaps some effort
should be made to expand upon $q's offering, or, in lieu of that, consider
renaming $q to something more generic like $promise, or $then?

Are there any objections to adding utility to $q? Are pull requests
welcome?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1998#issuecomment-26652854
.

chrisrhoden

[petebacondarwin]

@arhea - It appears that where $q is different to Q is only in the syntactic sugar methods. In terms of real functionality, the AngularJS $q library is now Promises A+ compliant: See #3699 and #3693.

Until we are in a position to allow the developer to completely swap out the $q promises library with Q, I think there is little to do. Closing this ticket.

If you want to push for adding these syntactic sugar methods then you can offer a pull request, such as @chrisrhoden's for adding promise.progress().