Has a best practices for destroying an angular app been established ? If I bootstrap and angular app onto an element. How would I go about un-bootstrapping it?
...Would I just call $destroy on the $rootScope then remove the element from the DOM? There are quite a few things I'm not familiar with (the internals). I'm trying to catch up with this thread (and another on github). So thanks for any pointers! On Thursday, November 8, 2012 at 12:33:35 PM UTC+2, [email protected] wrote: > > We have an application made up of "widgets" that are loaded dynamically > (via require), each widget is a separate angular application (via manual > bootstrap), we need to be able to un-install the widgets. So, basically we > need to tear down an angular application safely, without any leaks... > > As angular doesn't appear to have an "official" mechanism for tear down > (Issue > 1537 <https://github.com/angular/angular.js/issues/1537>), there is no > way to tell the injector to dispose of all of its services, therefore, > services such as browser which attach to window events have no idea that > they should detach their event handlers, this leads indirectly to the root > scope being held onto. > > In our "widget" framework, when we destroy our context (which is similar > to angular's injector), the context's lifetime container calls dispose on > any services we are managing (if they support it), allowing them to perform > cleanup. > > It would seem that the angular way to do this would be for services that > attach to global events (such as browser) should attach to the $rootScope's > $destroy event. However, $rootScope currently ignores $destroy calls. An > alternative would be to use the mechanism above to support an > $injector.destroy() which cascades to all of its services. > > There are interesting issues to consider regardless, for example, what if > service A utilizes service (B) during its destroy and B has all-ready been > destroyed? This could potentially be managed by inspecting the dependency > tree, however, manual resolutions through "get" would fail. Alternatively a > two phase tear down may alleviate these issues (but would require > developers to understand the cycle), yet another alternative would be to > say fine, use B, its unhooked from anything global, and will just return > you default responses. > > I need a solution for our application so will be forking the source, so > some feedback would be good, as I'd like to consider putting together a > proper solution that can be shared :) > > > -- 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.
