Laurent Perrin

@DevBaptist, disabling all watchers is not a big deal because you are only disabling them for a single $digest cycle.

The idea is to make some $digest cycles super fast, for example if you are in a scroll event and you are only interested in making new cells visibles. Watchers will still be processed by other digests so your app will keep rendering correctly.

@eolognt: I am only removing removing watchers from scopes that have the fa-suspendable directive.

Typically, in a very long list, you'd use this to suspend the watchers of individual cells, while keeping those on the list itself. It would allow you to quickly render new cells as they become visible and hook a $digest cycle on the scroll event.

Yeah, but the use-case is really to do something like suspend / digest / resume during a scroll event. You are not expected to add new watchers.

@felikz

If they are managed by a driver, it might keep them open without your knowledge. What I do is that I wrap each socket in a domain (http://nodejs.org/api/domain.html) so I can have some context (why and when it was opened, when it's supposed to have closed, etc.). Then if I get leaked sockets, I can always pull the domain and see the history of the socket.

@felikz

The most common reason is if you have a missing callback: you return from an async function without ever calling the callback and your connection just stays open "forever" (until a TCP timeout eventually occurs).

In my case, I had lots of persistent connections and the reconnection algorithm sometimes didn't close the previous connection.

That's exactly what I do, I have a "fa-suspendable" directive that activates the code (see in the example).

To prevent the scroll bar from disappearing, I adjust the top and bottom padding of the container so that it replaces the space where the missing cells are.

Sure, here is the full directive:

https://gist.github.com/lperrin/123be96bfff9d0a9697a

$apply will check all the watchers of the app, while $digest will only check the current scope and its children. In my case, I'm only interested in detecting changes in the list and I need to go as fast as I can because the scroll event fires very often.

Hadn't thought about that. Thanks for sharing!

If you use $rootScope.$emit, you (obviously) need to use $rootScope.$on in your scopes. Problem is, you scopes will not automatically unregister when they are destroyed and you must do it manually:

var unwatch = $rootScope.$on('bla', …);
scope.$on('$destroy', unwatch);

I've seen my app leak like mad because of that, so I avoid that now unless I have to, but you're right: it would be faster :)