Q resolve outside of $digest

[icholy]

I have a lot of code in services that use Q promises for async stuff. I can't use $q because it only resolves in a $digest cycle. I really don't want to include 2 copies of the Q library but, by the looks of it, I have to.

I don't know if this has been discussed, but could there be another method added to deferreds? Something like deferred.resolveNow(/* stuff */) which doesn't use nextTick

[0x-r4bbit]

If you use a Q implementation which lives outside of angular world, wrap the calls in $rootScope.$apply to kick a $digest

[andi1984]

This is really annoying...

I also worked on an app with a lot of chained digest events. Q implementation should definitely live inside the angular world or should be integrated!

It's weird that execution sometime stops and proceeds when an UI interaction happens. At least on some mobile devices.

[icholy]

@PascalPrecht starting a $digest every time I use a promise is not an option for me. There are performance considerations.
EDIT: misread your comment the first time. I want to avoid an external Q altogether.

[0x-r4bbit]

@andi1984 Uhm... there is a Q implementation inside of angular ? Just use $q service :)

[andi1984]

@PascalPrecht No, I'm already used the $q service, but it seems that some mobile devices have problems with chained callbacks, at least via the $q service.

The execution stops at some deeper level and proceeds when a new UI interaction was done.

[icholy]

@andi1984 it's like that so you can use promises in your model data & templates and have it work as expected.

[bfanger]

I've a jsFiddle which indicates the complexity of using $q http://jsfiddle.net/Lpadg/

I think the problem is nextTick in angular. Which could/should schedule the tick handler.

// in nextTick
if (!tickScheduled) {
  tickScheduled = true;
  setTimeout(function () {
    tickScheduled = false;
    handleTick();
  }, 0);
}

[andi1984]

@bfanger The problem could be caused by iOS itself, having problems to schedule the ticks? Issue #2942 could be correlated to that. I'm not an AngularJS Pro, but it could be caused by the same tick scheduler issue.

[mgcrea]

Encountering this as well (see #2993), exposing qFactory could solve theses kind of issues as we would be able to setup a custom $q service with a $scope-independent nextTick().

[dcherman]

It seems silly to have promises only become resolved once a $digest() happens imo.

Consider the following:

setTimeout(function() {
    $http.post( "some-logging-url" );
});

Nothing in there explicitly should require a $digest() to occur, so requiring that code to be wrapped in a $timeout seems silly, however that request will actually never happen until a $digest() occurs since internally $http calls $.when( config ). That behavior is rather surprising, at least to me.

What's the actual benefit of tying a promise's resolution to the $digest() cycle in the first place?

[andi1984]

@dcherman

What's the actual benefit of tying a promise's resolution to the $digest() cycle in the first place?

That's the main question. I also didn't and still don't get it.

But related to isssue #2894, it seems that you have to wrap it by a manual $applycall:

$rootScope.$apply(function(){ 
    deferred.resolve(data);
});

But, as you, I don't see any deeper sense in that...

[mgcrea]

@andi1984 in fact you can't rely on $apply as in some cases (like multiple stacked calls), it will trigger the angular-BSOD, $digest already in progress. The only safe option is to use $timeout, way too hacky imho.

What's the actual benefit of tying a promise's resolution to the $digest() cycle in the first place?

I think it was a way to minimize rendering iterations as promises are somehow queued to the $digest cycle and are all resolved at the same time (at the beginning of the next digest). It is a clever design choice, but we need to be able to use actual $q promises for out-of-angularjs world stuff. In my case, Phonegap/Cordova callbacks.

[icholy]

@mgcrea something like icholy@81bd59c example

The problem is $http still returns a $q promise.
If it returned a vanilla q promise it could be wrapped in a $q to get the old functionality

$q.when($http.get("url")).then(/* ... */);

Or there could just be another http service (without the $ prefix) which returns a vanilla promise.
That way we're not breaking backward compatibility.

EDIT If backward compatibility wasn't an issue you could rename $q.defer() to $q.$defer() and have $q.defer() return a non-angular deferred object.

[fallanic]

Same issue here, it's really annoying.
I'm currently using jQuery deferred to avoid weird behavior of my webapps, but would really prefer not to rely on an external lib.

[mgcrea]

@icholy have you submitted a PR with your patch? My use-cases are not bound to $http.

Any chance to get this into 1.1.6?