API to retrieve promise state

[cgross]

Right now $q promises don't have any way to get their state (pending, fulfilled, rejected). There's ajoslin/angular-promise-tracker that will keep track of $q promises for you but it really seems overkill to have such a project simply because there's no way to get $q promise states.

Would suggest something like Q has with isFulfilled(), isRejected() and isPending().

[aaronleesmith]

+1

[ghost]

+1

[ericeslinger]

+1 I was looking for where I could get $q.isPending, similar to Q.isPending and ended up here.

[costin-zaharia]

+1

[lord2800]

Is there a specific reason you need the state of a promise? Because in general, you can just chain on .then().

[cgross]

When you want to have an element visible during the duration of a promise.

ng-show="myPromise.isPending()"

[lord2800]

Got it. It's not exactly elegant, but what about:

$scope.isDone = false;
myPromise.then(function () { $scope.isDone = true; });

? Like I said, quite ugly, but it would suffice for now.

[cgross]

Thanks. We have various solutions today. This issue requests a simpler straightforward way.

[rinatio]

+1

[rinatio]

Hey guys, I'm trying to create some kind of flag if promise is resolved or not by decorating angular $q service, but it doesn't seem to be working. Here's a gits with decorator code. I need this flag to show loading indicator when ajax is in pending and I need it for many requests so it's better to keep it DRY. Since $http uses not decorated $q there's probably no other way to make it except add it to the core. Please advise

[rinatio]

Sorry guys, finally got it working, my fault. Having a common api is better anyway I think. Thanks!

[xeronimus]

+1

[ashaffer]

+1. Of note, this data is actually present in the current version, but is not documented. promise.$$state contains all the information we need. However, I worry that its not being documented means we're not supposed to be using it and it is likely to change. Having a consistent documented API for this would be awesome.

[caitp]

Please don't use Promise#$$state ^_^ It would be a private symbol if we could change our supported browsers :d

[caitp]

(but seriously --- please don't use that in production, it's not going to result in well-designed code. However, I think that is a workable solution for this issue, so we can probably close this).

[caitp]

...myep I'm talking to myself, but gonna close this one for now unless people feel like touching private variables just isn't good enough.

[ashaffer]

Is it? Do you disagree that it would be desirable to have a codified API similar to this?

[caitp]

@ashaffer the issue with such apis is, people tend to use them like this:

function ambiguouslySyncOrAsync(promise) {
  if (promise.isPending()) {
    // do async pathway
  } else {
    // do synchronous pathway
  }
}

And this is a pattern that you really don't want to have. Checking the promise state can certainly be valuable during testing, but is generally something you want to avoid, just to make sure code is structured in a simple and sane way.

[ashaffer]

@caitp Ya I agree with that, it's just pretty nice for certain things. Testing is one instance, and also showing spinners and other loading related status information. It can also be nice for showing/hiding things at the appropriate times.

[cgross]

I would really appreciate this being reopened. My use case is to show something in the UI while a promise is running. So put the promise on scope and reference an isPending() method or similar. This need is common enough that multiple projects have sprouted up to try to handle this including angular-promise-tracker and my angular-busy. But we have to write really nasty code to determine promise state instead of having a simple method.

Most promise libraries that I look at including Q, bluebird, and RSVP all include some way to synchronously determine a promise's state.

[caitp]

@cgross, as was mentioned, you can reference the $$state variable --- it's private, but it probably isn't going anywhere since we can't use symbols in 1.x.

One thing you could do is put together a module which monkeypatches these methods onto the promise prototype.

[martinth]

Why is this closed? Either $q should be updated or at least the documentation should make it crystal clear that it's only a subset of Q.

The documentation to $q starts with

This is an implementation of promises/deferred objects inspired by Kris Kowal's Q.

and links to his project. For me and probably many other people means "Yeah, we took his API and some of his code and adapted it to angular". It definitively doesn't read like "We implemented three methods and were done". So can we either get the full Q API (which would also make $q promises compatible with anything that works with Q) or at least add a sentence that makes the difference clear?

[sime]

Is it possible without using $$state, to determine if a $http error is triggered by a resolved timeout promise or not.

[kkavod]

Please re-open this issue since it's not fixed and the $$state "workaround" is not acceptable.

[AnimaLupi]

I'll add myself to the list of people that would like to have the possibility to check promise state synchronously as it can be done in Q or similar libraries. There are situations when this functionality can be extremely useful and a lot cleaner to use than some .finally implementation.

For example, I stumbled on this issue while writing a queue service for several async operations that should run in parallel or serialized (and a mix of the two) based on different resource type being operated upon.

[p0lar-bear]

While I agree that this could lead to plenty of antipatterns from less experienced developers, right now there is no guaranteed way for me to reliably check on the status of a Promise to report async operations back to the user. It's more trouble than it's worth to have a promise update a scope/controller variable through watches or .then() callbacks when we could just plop promise.inspect().state === 'resolved' or promise.isResolved() into a template.