backbone.js - Backbone js .listenTo 与 .on

Question

下面两行代码的优点和缺点是什么？我不明白为什么有两种不同的方法来做同样的事情。

this.listenTo(app.Todos, 'change:completed', this.filterOne);
app.Todos.on('change:completed', this.filterOne);

另外，当使用 .on 时，如何确定是否是默认上下文？

Answer 1

listenTo是更新更好的选项，因为这些监听器将在 stopListening 期间自动为您删除。当 View 被删除时调用(通过 remove() )。之前 listenTo幻影 View 永远存在(泄漏内存并导致不当行为)是一个非常阴险的问题，因为 View 方法被引用为模型上的事件监听器，即使 View 实例本身早已消失并且不再存在于 DOM 中。

如果您想阅读 listenTo 的背景故事，在主干 github 存储库中搜索 listenTo并通读一些较长的问题讨论。

对于默认上下文，有几件事最终可能会绑定(bind)到 this :

• 如果您通过 this.listenTo 进行绑定(bind)，它将始终是 View 实例(由 Wim Leers 在评论中指出)
• 没有 this.listenTo ，故事变得复杂
  • 对于其他事件，它将是全局对象(最好避免这种情况)
  • 对于 DOM 事件，它将是源元素，就像常规 DOM 事件绑定(bind)一样
  • 如果您提供明确的上下文( foo.on 的第三个参数)，backbone 将使用它(因此这是一种更稳健的方法)
  • 如果您使用 ECMA 标准 function () {//your event handler}.bind(this) ，您也可以手动控制上下文(也推荐)
  • 正如 @mu 指出的那样，_.bind或$.proxy有 ECMA 的可用替代方案 function.bind
  • 对于 Backbone View ，执行 this.bindAll('onClick', ...)将确保 View 实例是 this当任何 View 方法用作事件处理程序时的上下文
• 使用 View 标准连接的任何事件 events属性将通过主干自动为您绑定(bind)到 View 实例(这是带有 bindAll 的腰带和吊带)

总结为一些准则:

• 使用 events尽可能简洁且正确的属性
• 使用this.listenTo对于模型和集合的所有绑定(bind)
• 任何其他绑定(bind)请记住使用您首选的方法可靠地绑定(bind)上下文。我通常使用ECMA Function.bind因为嘿，标准，但这里有几个不错的选择。