Provide an overload for $timeout that doesn't take a function #9176

Closed
benjamingr opened this Issue Sep 19, 2014 · 10 comments

Projects

None yet

5 participants

@benjamingr
Contributor

I propose a $timeout variant that takes only a duration parameter.

There are two primary use cases I can think of

It would be really nice to be able to do:

$timeout(100).then(function(){
    // do stuff here, this runs a digest if it needs to which the
    // $timeout(function()... variant does not since 19b6b34
})

As well as

myServiceFn().then(function(res){
    // do something
    return $timeout(300);
}).then(function(){...

Which is rather common and today is accomplished by return $timeout(angular.noop, 300) which feels redundant and rather ugly.

This could be accomplished by adding a simple check here and I wouldn't mind creating a PR if you would entertain one.

@lgalfaso
Member

This looks reasonable

@gkalpak
Member
gkalpak commented Sep 19, 2014

According to @caitp (#9175 (comment)) $timeout should still invoke $apply() if the invokeApply argument is not specified or truthy (if it doesn't then it is a bug and should be fixed).

If that is indeed the case, then I don't see this change making any difference.

@caitp
Contributor
caitp commented Sep 19, 2014

yes, I'm going to see if I can reproduce what they're talking about, because this was tested manually before

@caitp
Contributor
caitp commented Sep 19, 2014

http://jsbin.com/tesaqovopaza/1/edit can't reproduce at all

@caitp
Contributor
caitp commented Sep 19, 2014

Wait hang on, these things are talking about two very different issues ^_^

@gkalpak
Member
gkalpak commented Sep 19, 2014

@caitp:
What I said is that if the other issue is not an issue (i.e. if $timeout is working as expected), then the modification proposed in this issue is not particularly valuable.

I.e. everything that will be possible using $timeout(100).then(callback) is already possible using $timeout(callback, 100). (It's even less code with the current implementation.)

@caitp
Contributor
caitp commented Sep 19, 2014

yeah, I sort of agree that it's a weird feature to add, but if people really want it, it probably won't account for much code

@benjamingr
Contributor

@caitp here is a fiddle illustrating it working after a .then -http://jsfiddle.net/c8rchefp/ here is it not assimilating a promise without a .then http://jsfiddle.net/x4y3kjzf/ which is not what I'd expect.

After a second check this is not the breaking change since promises returning promises don't schedule a digest at the current moment anyway (although that's not the behavior I'd expect).

I'm still all for this feature though for the promise chain use case regardless of this. I'll close the PR on the other issue, my bad.

@caitp
Contributor
caitp commented Sep 19, 2014

http://jsfiddle.net/3n9akpdg/ --- works this way. It looks like something is wrong with the way we're dealing with external promises, you should file a bug on $q

@benjamingr
Contributor

@caitp it's not a bug since the digest system is completely orthogonal to the concerns of the Promises/A+ specification. Looking back at how $q behaves in 1.2 this is not a change. The overload is still nice for the promise chain case.

I'll write a PR for this in the next few days and accompanying tests.

@btford btford added this to the Backlog milestone Sep 19, 2014
@vasileorza vasileorza added a commit to vasileorza/angular.js that referenced this issue Oct 21, 2014
@vasileorza vasileorza feat($timeout): overload service API.
Provide an overload for $timeout that doesn't take a function.

Closes #9176
6b69480
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment