是否应该使用listenTo/stopListening替换所有Backbone开/关事件？

Question

据我已经能够告诉,listenTo并stopListening应更换on和off分别.我理解正确吗？是否有任何情况应该on/ off应该使用而不是listenTo/ stopListening？

编辑:

当我去重构我的代码时,很明显有些情况可以on结束listenTo.该文档是很清楚,它是当一个对象监听到另一个对象:

告诉一个对象来听一个特定事件上的其他对象.

因此,当a collection或model正在听自己的事件时,我们应该使用on而不是listenTo.

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

遵循的简单规则是:

listenTo在侦听另一个对象上的事件时使用.on在听取自我事件时使用.

Answer 1

复制我最近阅读的有趣博客文章的摘录.希望能帮助到你.

避免常见的主干陷阱:通过不解除绑定事件来创建内存泄漏

Backbone.js中的一个常见模式是创建侦听模型或集合中的更改的视图.此技术通常旨在允许视图在基础数据更改时自动重新呈现.这也意味着对于大型集合,我们可能会得到许多视图(对于集合中的每个模型至少有一个视图),我们可以根据对数据的更改动态创建或销毁这些视图.

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

以此视图为例:

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

调用.remove()方法时,仍然绑定"change"事件处理程序(我们的render函数).因此,虽然可以删除DOM元素,但视图对象本身永远不会从内存中释放.

解决这个问题很容易(特别是因为Backbone 0.9.x) - 我们需要做的就是在绑定事件处理程序时停止使用.on().相反,我们可以使用新的.listenTo()方法,如下所示:

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

这里最大的不同是责任从模型转向视角.这意味着每当我们调用.remove()时,视图将使用.listenTo()方法自动取消绑定绑定到它的任何事件,从根本上修复此常见泄漏.

Answer 2

在大多数情况下,您正确理解它.以下是来自他们的github存储库的讨论:https://github.com/documentcloud/backbone/issues/1923#issuecomment-11462852

listenTo并stopListening跟踪状态.它将以一点代码开销为代价为您进行清理.几乎在每种情况下,我都能想到你希望这种行为适合你的观点,但你自己处理开/关电话也不会有错; 他们不会贬低on,也不会off很快.