14

私が知る限り、それぞれlistenToとstopListeningを置き換える必要がonありoffます。私はそれを正しく理解していますか？/の代わりに/を使用する必要があるon状況はありますか？offlistenTostopListening

編集：

onコードをリファクタリングしようとすると、オーバーの場合があることが明らかになりましたlistenTo。ドキュメントは、あるオブジェクトが別のオブジェクトをリッスンする場合のものであることを明確に示しています。

他のオブジェクトの特定のイベントをリッスンするようにオブジェクトに指示します。

したがって、collectionまたはmodelがそれ自体でイベントをリッスンしている場合は、onの代わりにを使用する必要がありlistenToます。

私がこれを正しく持っていると仮定して...

従うべき簡単なルールはこれです：

listenTo別のオブジェクトのイベントをリッスンするときに使用します。on自分でイベントを聞くときに使用します。

4

2 に答える 2

14

最近読んだ興味深いブログ投稿からの抜粋をコピーします。それが役に立てば幸い。

一般的なバックボーンの落とし穴の回避：イベントのバインドを解除しないことによるメモリリークの作成

Backbone.jsの一般的なパターンは、モデルまたはコレクションの変更をリッスンするビューを作成することです。この手法は通常、基になるデータが変更されたときにビューが自動的に再レン​​ダリングできるようにすることを目的としています。また、大規模なコレクションの場合、データの変更に基づいて動的に作成または破棄できる多くのビュー（コレクション内のモデルごとに少なくとも1つ）が作成される可能性があることも意味します。

この問題は、ビューを削除するときに発生しますが（通常、その.remove（）メソッドを呼び出すことによって）、モデルの変更をリッスンするメソッドのバインドを解除するのを忘れます。このような場合、コードがそのビューへの参照を保持しなくなったとしても、モデルがイベントハンドラーを介してそのような参照を保持しているため、ガベージコレクションされることはありません。

このビューを例にとってみましょう。

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

.remove（）メソッドを呼び出すと、「change」イベントハンドラー（レンダリング関数）は引き続きバインドされます。したがって、DOM要素は削除できますが、ビューオブジェクト自体がメモリから解放されることはありません。

これを解決するのは簡単です（特にBackbone 0.9.x以降）-イベントハンドラーをバインドするときに.on（）の使用を停止するだけです。代わりに、次のように新しい.listenTo（）メソッドを使用できます。

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

ここでの最大の違いは、モデルからビューへの責任のシフトです。これは、.remove（）を呼び出すたびに、ビューが.listenTo（）メソッドを使用してバインドされたイベントを自動的にアンバインドし、この一般的なリークを本質的に修正することを意味します。

于 2013-03-27T23:50:36.153 に答える
10

ほとんどの場合、あなたはそれを正しく理解しています。これが彼らのgithubリポジトリからの問題に関する議論です：https ：//github.com/documentcloud/backbone/issues/1923#issuecomment-11462852

listenTo状態をstopListening追跡します。少しのコードオーバーヘッドを犠牲にして、クリーンアップを処理します。ほぼすべての場合において、私はあなたがあなたの見解に対してこの振る舞いを望んでいると思うことができますが、あなた自身もオン/オフ呼び出しを処理することに責任はありません。それらは廃止されることはなく、すぐonにoffいつでも。

于 2013-03-26T19:35:30.410 に答える