You can find the troublesome directive by searching for cleanupElementNgGrid in the ng-gird-selfCleaning.js source file.
Thanks. On Saturday, October 4, 2014 7:46:55 PM UTC-4, Jesse Wolfe wrote: > > Hello All... > > Been searching for awhile in the archives and on the 'net for an answer, > but not really finding one, just bits and pieces. Perhaps someone here can > help me pull together what's going on. > > I have a complex directive which is using scope: true. It's actually the > ng-grid latest 2.x version that I'm trying to write cleanup code for, since > it just is leaking memory like crazy, and our app is "stuck" with it for > now. Here's the plunk that demos the problem > <http://plnkr.co/edit/BMoCp4sRcdq6KgguvqGz>. When you click through the > grid and check the heap snapshots afterwards, you'll see several > "unattached" ngGrid objects. These are only held down by listeners on the > directive's scope. > > When I'm changing states (using ui.route latest) by clicking through the > multple grids (states), the grid directive's scope IS getting the $destroy > event. The handler is working. However, the scope itself is NOT getting > $destroy() called on it. I see in the heap snapshot that the directive's > scope is still holding onto elements via $$listeners. Also, > scope.$$destroyed is not set. > > However, scope._prototype_ *IS* destroyed. And because it is, I can't > even call $scope.$destroy from the directive's $on-$destroy handler, since > the proto's $destroy() call changed the definition of $destroy to noop. > > Setting scope.$$listeners = {} with a $timeout of 2000 (to give time for > the directive to finish cleaning up in my on-$destroy listener seems to > work , but it feels wrong to munge with the internals, and sometimes it's > not long enough for the browser to finish the cleanup. It's just a > work-around/kludge. > > *So what is preventing my directive's scope from getting $destroy() > automatically called on it? * > > At first, I thought it was because we use scope: true in the directive > options, since the proto scope seems to have been destroyed. So I wrote a > plunk to try that theory out. <http://plnkr.co/edit/ucqlRC> But with this > plunk, the directive's scope is properly destroyed and no objects are > leaked. Very surprising, actually. But I don't use the same view nesting I > have in the first plunk; however I doubt that's it. Controller scope still > gets wiped when the views change. I still have a watcher on an internal > object. So I would think I'd see a similar dynamic. But it appears that > $destroy is really called on that internal scope. > > Any ideas about what would prevent a directive scope from getting > $destroy() called on it? IT seems related to the scope: true bit, but I > can't quite grok Angular internals enough to say why. > > Thank you in advance, > > Jesse > > > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
