ngMock $interval uses promises to fire callbacks which depend on $apply

[kseamon]

If the invokeApply param is passed as false, callbacks registered with $interval will not fire (without a subsequent manual call to $apply).

This is because promises fire during the digest cycle on $rootScope.

[IgorMinar]

this is related to #2049 in that we need promises to work outside of the digest cycle.

I agree that this is stupid. we shouldn't have exposed the invokeApply api in this case as we can't really make it work well.

$timeout is also partially broken because of this.

[IgorMinar]

I don't have a solution to this yet. The right solution would be to somehow disconnect the promise life-cycle from digest, but that's a tough issue to solve as it touches so many things starting from testing ending with performance and coalescing of work before dirty-checking and repaints.

[kseamon]

The mock could also be refactored to not use promises. It doesn’t seem like they are serving much purpose in it anyway.

On Feb 3, 2014, at 7:30 PM, Igor Minar [email protected] wrote:

I don't have a solution to this yet. The right solution would be to somehow disconnect the promise life-cycle from digest, but that's a tough issue to solve as it touches so many things starting from testing ending with performance and coalescing of work before dirty-checking and repaints.

—
Reply to this email directly or view it on GitHub.

[IgorMinar]

I think we have a similar issue for $timeout as well

[IgorMinar]

@kseamon how would that work. the real $interval returns a promise, the mock has to as well. I don't think that mock can somehow work around this bigger issue unless we want to make mock not behave like the real implementation which is a really slipper slope to walk on ;-)

[kseamon]

It didn't occur to me to check the original $interval's implementation (I filed the bug against ngMock after all). Yes, that would make things trickier, but that just means the original should probably be decoupled from promises as well.