-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Root scope dirty check triggered by a child scope's apply #8184
Comments
I totally agree with this poster. Scope.$apply gets called super commonly in angular -- for instance on ANY of the ng-event type of directives -- and I don't want some hundred item ng-repeat directive getting dirty checked every time a user does an ng-click on some completely unrelated portion of the page. At the very least, why not make this behavior configurable in $rootscopeProvider at this location. It would be simple enough to add another method to the provider and then conditionally call scope.$digest instead of $rootscope.$digest. I'd be happy to volunteer if anyone else thinks this is a good idea. |
That is not really the solution as many directives do create child scopes hence you'd want the $digest to be called on a parent up the hierarchy chain, rather than on the scope attached to the directive. We need a way to define a containment of the digest when $apply is being called. So how about adding a special marker on the scope which indicates that an $apply should not pass its boundary upstream. We then change the $apply method's logic to be something like:
That means that for example in the constructor of my controller I'd say:
and whilst making sure the data attached to the scope doesn't bleed into other sibling or parent scope, any directive accessing this scope or a child scope won't cause dirty checks everywhere. |
This is a duplicate of #8055 |
Most directives call $scope.$apply, which is currently poorly implemented in Angular. The call is proxied to $rootScope.$digest, which has the effect of dirty checking ALL the scopes.
As I'm in charge of hooking up the data onto the scopes, I already know what needs to be dirty checked and what not. If I've set up my data to flow inherently the same as the scopes, there should be an option inside Angular to tweak the default nasty dirty-checking behaviour.
This naive design decision has massive performance implications.
The text was updated successfully, but these errors were encountered: