-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[$multiWatch] simplified the code and fixed a race condition #3685
Conversation
92c6374
to
fb0282a
Compare
@@ -34,80 +34,70 @@ define(function (require) { | |||
* @param {boolean} deep - should the watchers be created as deep watchers? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this from the docblock
fb0282a
to
0759c97
Compare
This seems fine, but I'd like to spend some more time with it, as well as apply it against #2518 since that's how I found the original issue. In the meantime, and since this should probably have a couple sets of eyes on it anyway, I'm going to send this to @lukasolson for now. Lukas, please assign back to me after you've had a chance to check it out. |
I've played around with a couple areas of the application that use |
Looks good against #2518, and I can't find any issues with it. |
[$multiWatch] simplified the code and fixed a race condition
While debugging an issue with @w33ble we noticed a race condition in
$multiWatch
.When
$multiWatch
triggered the change handler, the values being passed in did not match the actual values defined on scope. This was happening because a child$scope
modifies the value being watched in the same digest cycle that the parent watcher triggers. Generally data flows top down but the filter bar is says "screw the trickle down effect!", which drew out this bug.This test was added to simulate the necessary conditions.
While considering solutions, I learned that
$watch
handlers are always executed in order, so I was able to simplify the logic and have the handler execute in exactly the same position as a normal would (as opposed to using$scope.$evalAsync
)