Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

$timeout no longer causes a digest #9175

Closed
wants to merge 1 commit into from

Conversation

benjamingr
Copy link
Contributor

Since 19b6b34 $timeout no longer causes a digest - because of this the examples in this page no longer work. I've updated them using the suggested workaround.

Since angular@19b6b34 $timeout no longer causes a digest - because of this the examples in this page no longer work. I've updated them using the suggested workaround.
@caitp
Copy link
Contributor

caitp commented Sep 19, 2014

Can you post some code? It should only skip apply if you pass a defined falsy value as the invokeApply argument

@caitp caitp self-assigned this Sep 19, 2014
@caitp caitp added this to the Backlog milestone Sep 19, 2014
@caitp
Copy link
Contributor

caitp commented Sep 19, 2014

I mean, post some code specifically about what you're doing with $timeout to get the behaviour you're talking about

@benjamingr
Copy link
Contributor Author

I was in the process of making a PR when finding the change and posting this. I'll make a self contained example when I get home in a few hours

On 19 בספט׳ 2014, at 16:08, Caitlin Potter [email protected] wrote:

Can you post some code? It should only skip apply if you pass a defined falsy value as the invokeApply argument


Reply to this email directly or view it on GitHub.

@caitp
Copy link
Contributor

caitp commented Sep 19, 2014

The thing is, you can see the code right there: if invokeApply is a defined variable which is not falsy, (in other words, if you omit the parameter entirely), it will use the original $q implementation and call $rootScope.$apply() once the timeout is finished. This is pretty self-evident in the code.

If invokeApply is some other falsy value, then we don't call $apply(), and use a version of $q which does not trigger a digest.

There is no reason this shouldn't work for you, so I would be interested in seeing the specific code you're actually using to cause problems

@caitp
Copy link
Contributor

caitp commented Sep 19, 2014

If $q is not triggering a digest, the $apply will, so there's really no reason why you should need to add a then() handler to work around anything. I am very confused how you're managing to make this not work for you

@caitp
Copy link
Contributor

caitp commented Sep 19, 2014

@benjamingr benjamingr closed this Sep 19, 2014
@benjamingr benjamingr deleted the patch-1 branch September 19, 2014 14:44
@benjamingr
Copy link
Contributor Author

Sorry, this is my bad. I expected digest scheduling to be more well behaved with promise assimilation. I'd expect

myAngularService().then(function(){
    return myParseApiMutator().then(function(bar){ // or other non $q promise 
          $scope.foo = bar;
    })
})

To schedule a digest once the promise created by the then in myAngularService to resolve. I associated this not happening with the change and I'm at fault here for not reading the code closely enough. Closed the PR. Thanks and sorry.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants