在 View remove()
方法中调用 undelegateEvents()
是一种不好的做法吗?为什么 Backbone 人员默认不包含它?
我意识到我在简单地重新初始化 View 变量时遇到了很多绑定(bind)问题。虽然在创建新 View 时会自动调用 undelegateEvents()
,但它会尝试取消委托(delegate)新实例化 View 的事件,而不是前一个 View 。因此,除非每次都手动调用它,否则幽灵事件回调仍然存在并搞砸了我的应用程序。
处理此问题的最佳方法是什么?
最佳答案
Is it a bad practice to call
undelegateEvents()
in the viewremove()
method?
没有必要,除非您正在实现自己的 remove()
并且您不调用 Backbone.View.remove()
或 this.$ el.remove()
。至少,如果您使用的是 jQuery。在 Backbone View 上调用 remove()
将调用 jQuery.remove()
,无论如何都会删除所有 DOM 事件监听器。
I realized I am falling into so many binding issues, when simply reinitializing a view variable.
很多人似乎都在使用 Backbone.Events,就像它是一种他们不需要在之后清理的魔法,例如:
var View = Backbone.View.extend( {
initialize : function ( options ) {
// `on()` or `bind()`
this.model.on( 'something', this.render, this );
}
} );
请参阅我在 Delegating events to a parent view in Backbone 上的回答
您遇到的幽灵事件问题是否可能与 Backbone 事件有关,而不是 DOM 事件?
如果您保留模型对象但想摆脱该 View 对象或其 Backbone 事件注册,则必须执行 view.model.off(null, null, this );
。您必须取消绑定(bind)您在任何外部对象上注册的事件。如果需要,您可以重写 Backbone.View.remove()
并在那里执行它,但默认情况下,该方法只是 view.$el.remove()
的简写.
关于javascript - 一旦不再需要 View ,取消委托(delegate)事件的最佳方式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10734210/