Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What problems did you encounter with dirty checking?


The way AngularJS works is that it allows you to use plain ol' JS objects all over the code and allows you to implicitly/explicitly set-up "watches" on these JS objects. Whenever the value of the object changes, your app is given a chance to react to it. When you use these objects in your view, the "reaction" is implicit, i.e. the view gets automagically updated.

However, the process of checking whether JS objects have changed, is not very pretty. AngularJS maintains a copy of every object in the "scope". After every "digest cycle", Angular compares the copy of each object with the previous known state/value and figures out what changed. (I'm sure internally they're using really tight loops & optimized code to make this fast).

A "digest cycle" is triggered after every event that may possibley change the state/value of the tracked JS objects. Eg. a keypress, an HTTP event, a click, etc.

When you have several-thousand bindings, each digest cycle gets computationally very intensive and the app starts to feel sluggish. Typing a key in a form-field and waiting for it to appear on the screen, can also lag. Please note: this happens if you have several-thousand bindings on one page -- something that is actively discouraged in the Angular world.

In my case, I was building a dashboard app, where the nature of the app required me to show several thousand data-points with the option of "zooming-in" or "zooming-out" from data points (not in the visual sense).

Later, I realized that this limitation is easily overcome if you stop using the implicit two-way data bindings provided by Angular for such cases. If you know that those JS objects aren't really going to change with every digest cycle, it's best to not use {{ var }} to display them in your views and come-up with a custom directive that does NOT set-up a watcher on the variable. The downside is that you have to manually update your views whenever the underlying data does actually change -- not very different from how EmberJS does it.


Thank you for this explanation. I didn't quite 100% grok how it worked, and had heard there was some kind of limitation around it, but didn't know the details. This was very clear.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: