2014-12-15 19 views
8

Oggi non riesco a trovare la risposta attraverso una domanda angolare molto "dal naso di coniglio". Dai documenti $scope, è possibile registrare un gestore di eventi su "$destroy", chiamato prima della distruzione dell'ambito. In questo modo, è possibile annullare la registrazione gestori di eventi in questo modo:

var deregister = $scope.$on('myCustomEvent', function() { 
    // do some crazy stuff 
}); 
$scope.$on('$destroy', function() { 
    deregister(); 
}); 

Tuttavia, il $scope.$on('$destroy', ...) necessario creare il proprio gestore. Viene automaticamente distrutto o devi fare qualcosa del genere per distruggerlo?

+0

Sì, viene distrutto - ovviamente se fa riferimento a qualcosa di esterno il gestore stesso (e quindi tutto ciò che ha nella sua chiusura) non verrà deallocato (proprio come ovunque altrove). –

+0

Immagino che le domande di follow-up sarebbero allora (a) è necessario deregenerarlo, e (b) in caso affermativo, è possibile cancellarlo anche nel modo in cui ho scritto sopra? – jdotjdot

+0

Naa, hai solo una ricorsione infinita - non hai bisogno di cancellarla, l'obiettivo viene distrutto. Sono sicuro che presto qualcuno con più tempo farà una risposta decente e dettagliata qui :) –

risposta

1

La risposta è in realtà "forse" a seconda di ciò che si intende quando viene automaticamente distrutto. Se guardiamo all'origine per il metodo $destroy per gli ambiti, possiamo vedere che mentre un evento $destroy viene trasmesso verso il basso attraverso gli ambiti figlio, il metodo effettivo $destroy non viene mai invocato su alcun ambito ma quello iniziale. Ciò significa che l'effettiva pulizia e annullamento delle proprietà non si verifica mai sugli ambiti figlio.

La ragione per cui questo non è perdita di memoria, perché una volta $destroy è stata invocata in un ambito, che si stacca dal campo di applicazione genitore ed è quindi idoneo per la raccolta dei rifiuti in quanto dovrebbe non hanno più alcun percorso per la GC Roots. Questa stessa logica si applica a tutti gli ambiti figlio poiché anch'essi non dovrebbero avere percorsi per i GC Root.

Tuttavia, il tuo esempio è sicuro; Lo faccio allo stesso modo per ripulire i miei stessi gestori quando necessario e non incappare in alcun tipo di loop infiniti.