Czy wszystkie zdarzenia włączenia/wyłączenia szkieletu powinny zostać zastąpione przez listenTo/stopListening?

Question

O ile mogę powiedzieć, listenTo i powinny zastąpić odpowiednio: on i off. Czy rozumiem to poprawnie? Czy jest jakaś sytuacja, w której należy używać on/off zamiast listenTo/stopListening?

Edit:

Jak poszedłem do byłaby mój kod, stało się oczywiste, że istnieją pewne przypadki dla on nad listenTo. documentation jest całkiem jasne, że to jest, gdy jeden obiekt słucha innego obiektu:

opowiedzieć obiekt słuchać określonego zdarzenia w sprawie drugiej obiektu.

Dlatego, gdy collection lub model słucha zdarzenia na siebie, powinniśmy używać on zamiast listenTo.

Zakładając mam to prawidłowe ...

Prosta zasada brzmi tak:

Korzystając listenTo podczas nasłuchiwania zdarzeń na innym obiekcie. Użyj on podczas słuchania wydarzeń na sobie.

Answer 1

W większości przypadków rozumiesz to poprawnie. Oto dyskusja na ten temat z ich repozytorium github: https://github.com/documentcloud/backbone/issues/1923#issuecomment-11462852

listenTo i stopListening śledzić stan. Zajmie się sprzątaniem za niewielką opłatą. W niemal każdym przypadku mogę myśleć o tym, że chcesz tego zachowania dla swoich poglądów, ale nie byłbyś też winny za to, że sam/a używasz połączeń przychodzących/wychodzących; w najbliższym czasie nie będą one deprecjonować on i off.

Answer 2

Kopiowanie ekstraktu z interesującego blog post, który ostatnio czytałem. Mam nadzieję, że to pomoże.

Unikanie typowych pułapek szkieletowych: Tworzenie wycieków pamięci przez nie Rozpinanie wydarzeń

Wspólny wzór w backbone.js tworzy widoki, które słuchają w sprawie zmian w modelach lub kolekcji. Ta technika ma zwykle na celu umożliwienie automatycznego renderowania widoku po zmianie danych. Oznacza to również, że w przypadku dużych kolekcji możemy uzyskać wiele widoków (przynajmniej jeden dla każdego modelu w kolekcji), które możemy dynamicznie tworzyć lub niszczyć na podstawie zmian danych.

Problem powstaje, gdy usuwamy widok (zwykle wywołując jego metodę .remove()), ale zapominając o odwiązaniu metod nasłuchujących na zmianach modelu. W takim przypadku, nawet jeśli nasz kod nie może już zawierać odniesienia do tego widoku, to nigdy nie jest zbiorem śmieci, ponieważ model nadal posiada takie odniesienie za pośrednictwem procedury obsługi zdarzenia.

Weź ten pogląd na przykład:

var SomeModelView = Backbone.View.extend({ 
    initialize: function() { 
    this.model.on('change', this.render, this); 
    }, 
    render: function() { 
    // render a template 
    } 
}); 

Po wywołaniu metody .Wykręcić(), to „zmiana” obsługi zdarzeń (nasza funkcja render) jest nadal związany. Tak więc, podczas gdy element DOM może zostać usunięty, sam obiekt widoku nigdy nie jest zwalniany z pamięci.

Rozwiązanie problemu jest łatwe (szczególnie od wersji Backbone 0.9.x) - wystarczy, że przestaniemy używać .on() podczas wiązania procedury obsługi zdarzeń. Zamiast tego, możemy użyć nowej metody .listenTo() w następujący sposób:

initialize: function() { 
    this.listenTo(this.model, 'change', this.render); 
} 

Największą różnicą jest przesunięcie odpowiedzialności z modelu do widoku. Oznacza to, że za każdym razem, gdy wywołujemy funkcję .remove(), widok automatycznie odwiąże każde zdarzenie z nim związane przy użyciu metody .listenTo(), w istocie naprawiając ten typowy przeciek.