Das Ideale besteht darin, Ihren Code so zu schreiben, dass keine Bereinigung erforderlich ist.
Zum Beispiel, wenn Sie einen Beobachter als
observeWhatever: Ember.observer('whatever', function() {...
keine spezielle Teardown definieren notwendig. Wenn Sie einen Event-Handler wie folgt definieren, ist kein Abbruch erforderlich. Was aber, wenn Sie ein DOM-Ereignis für ein Element in Ihrer Komponente hören möchten? Wir sehen oft Menschen, die können sich nicht daran erinnern, ob sie in Ember oder jQuery sind Programmierung Dinge tun, wie:
setupWhatever: function() {
Ember.$('.foo.bar.baz').on('click', function() { alert('baz clicked!'); });
}.on('init')
Das ist so ziemlich ein Anti-Muster, und nicht nur, weil es sein müssen abgerissen. Es ist völlig durcheinander, wie man auf Teile der App verweist, wie man Rückrufe einrichtet und wie man mit Aktionen umgeht. Die Sache, die Sie als .foo.bar.baz bezeichnen, sollte eine eigene Komponente sein, die auf Komponentenebene einen eigenen Listener einrichtet. Es wäre eine Aktion senden, die behandelt werden würden wie folgt:
{{foo-bar-baz action=(action 'bazClicked')}}
actions: {
bazClicked() { alert('baz clicked'); }
...
}
Wenn Sie möchten, für Sie einen Haken, wie
listen: Ember.on('message', function() ...
, die auch zerrissen einzurichten wird nach unten.
Wenn ich Ember.addObserver in Komponente verwendet didInsertElement, sollte ich es entfernen Ember.removeObserver in willDestroyElement Methode.
Welche Art von Beobachter würden Sie einrichten in didInsertElement? Übermäßige Verwendung von didInsertElement ist auch ein Anti-Pattern. Wenn Sie Ember richtig verwenden, sollte es kaum nötig sein. Eine mögliche Ausnahme ist das Initialisieren eines jQuery-Add-Ons, wenn Sie so unglücklich sind, eines davon zu verwenden.
Wenn Sie aus irgendeinem Grund mit Timern arbeiten, müssen Sie diese möglicherweise beim Beenden abbrechen.