backbone.js - 是否应该用listenTo/stopListening 替换所有Backbone 开/关事件？

Question

据我所知，listenTo和 stopListening应该替换 on和 off分别。我理解正确吗？有没有什么情况on/off应该使用而不是 listenTo/stopListening ?

编辑:

当我去重构我的代码时，很明显有一些 on 的情况。超过 listenTo . documentation很明显，它适用于一个对象监听另一个对象时:

Tell an object to listen to a particular event on an other object.

因此，当一个 collection或 model正在监听自身的事件，我们应该使用 on而不是 listenTo .

假设我有这个正确的......

要遵循的简单规则是:

使用listenTo在监听另一个对象上的事件时。使用on在听自己的事件时。

Answer 1

复制一个有趣的 blog post 的摘录我最近读到的。希望能帮助到你。

避免常见的主干陷阱:通过不解除绑定(bind)事件造成内存泄漏

Backbone.js 中的一个常见模式是创建监听模型或集合变化的 View 。此技术通常旨在允许 View 在底层数据更改时自动重新呈现自身。这也意味着对于大型集合，我们最终可能会得到许多 View (集合中的每个模型至少一个)，我们可以根据数据的更改动态创建或销毁这些 View 。

当我们删除一个 View (通常是通过调用它的 .remove() 方法)，但忘记取消绑定(bind)监听模型更改的方法时，就会出现问题。在这种情况下，即使我们的代码可能不再持有对该 View 的引用，它也永远不会被垃圾回收，因为模型仍然通过事件处理程序持有这样的引用。

以这个 View 为例:

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

当调用 .remove() 方法时，“change”事件处理程序(我们的渲染函数)仍然被绑定(bind)。因此，虽然 DOM 元素可能会被删除，但 View 对象本身永远不会从内存中释放。

解决这个问题很容易(尤其是从 Backbone 0.9.x 开始)——我们需要做的就是在绑定(bind)事件处理程序时停止使用 .on() 。相反，我们可以使用新的 .listenTo() 方法，如下所示:

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

这里最大的不同是将责任从模型转移到 View 。这意味着每当我们调用 .remove() 时， View 将使用 .listenTo() 方法自动解除绑定(bind)到它的任何事件，基本上修复了这个常见的泄漏。