Question

据我所知，listenTo和stopListening应分别替换on和off。我理解正确吗？是否应该使用on / off代替listenTo / stopListening？

修改

当我重构我的代码时，on超过listenTo的某些情况显而易见。 documentation非常明确，它是指当一个对象侦听另一个对象时：

告诉对象在其他对象上收听特定事件。

因此，当collection或model正在收听某个事件时，我们应该使用on代替listenTo。

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

遵循的简单规则是：

在侦听其他对象上的事件时使用listenTo。在收听自我事件时使用on。

Answer 1

复制我最近阅读的有趣blog post的摘录。希望它有所帮助。

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

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

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

以此视图为例：

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

调用.remove（）方法时，＆＃34;更改＆＃34;事件处理程序（我们的渲染函数）仍然绑定。因此，虽然可以删除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。

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

2 个答案: