4 ms·
Time spent in the digest cycle scales proportionally to the product of how often a digest occurs, and how many watches there are - each should be roughly propor
by jhpriestley 12y ago
Time spent in the digest cycle scales proportionally to the product of how often a digest occurs, and how many watches there are - each should be roughly proportional to the size of the application, for an overall quadratic complexity. If watches trigger other watches then this also lengthens the cycle, so the growth is actually more than quadratic in the size of the application - as bad as cubic possibly, if most notifications between modules are accomplished by one watch function setting variables for another watch function to pick up.
Debouncing controls one of the terms - frequency of digest cycles - so the complexity grows somewhere between linear and quadratic. The only scalable solution is to minimize the use of watches. Fortunately, this is also a good idea from a code quality standpoint - watches are an unstructured control flow system, similar to GOTO, and should be avoided even if they were efficient.
- aarongray 12y agoWell said.
- aikah 12y ago> watches are an unstructured control flow system, similar to GOTO Any callback is a GOTO. in fact, any function call in C like languages IS A GOTO. So i'm not sure what is the point of saying that. $scope.$watch is at the center of angularjs architecture,there is no way to avoid it. And that's what makes angularJS awesome,seamless integration between the view layer and other app layers,without a single explicit event handler registration,mediator,observer,... (except for directives obviously). No JS framework but angularjs does that,not even React that needs a 3rd party library to integrate itself with a domain layer. That's why angularjs is so easy to use and beats everything else.
- voidr 12y ago> Any callback is a GOTO. in fact, any function call in C like languages IS A GOTO. If a function call would be a GOTO, then you wouldn't have a stack trace to look at in your debugger. I'm not sure what is the point in replying to a comment you don't actually understand. Angular's data binding model has a lot of shortcomings: angular.module("app").controller("SomeController", function($scope) { setTimeout(function () { $scope.someVar = 'happy debugging'; }, 500); });
- aikah 12y agoangular.module("app").controller("SomeController", function($scope) { setTimeout(function () { $scope.someVar = 'happy debugging'; }, 500); }); Your example is stupid 1/ you should use $timeout or you're just asking for troubles.If not then $scope.$apply 2/ use named function expressions Any async operation in angularjs needs to trigger a digest cycle,that's angular 101. You cant use a framework without actually understanding how it works at first place. Your point is moot because you are using an example that is a mistake at best , but more like a bad piece of code,in angularjs context.No serious angularjs developper would do that mistake,especially when you are supposed to test that piece of code,using a function you didnt inject in the controller.