14

据我所知，listenTo应该分别stopListening替换on和off。我理解正确吗？有没有应该使用 / 代替on/的情况？offlistenTostopListening

编辑：

当我去重构我的代码时，很明显有一些onover的情况listenTo。文档非常清楚，它适用于一个对象监听另一个对象的情况：

告诉一个对象监听另一个对象上的特定事件。

因此，当collectionormodel正在监听自身的事件时，我们应该使用on而不是listenTo。

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

要遵循的简单规则是：

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

4

2 回答 2

14

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

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

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

当我们删除一个视图（通常是通过调用它的 .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 回答