addEventListener中的EventListener接口对象

写在最前

遗漏的知识点：addEventListener的第二个参数不光可以传入一个函数，还可以传入一个实现了EventListener 接口的对象。

文档中的描述

listener

当所监听的事件类型触发时，会接收到一个事件通知（实现了 Event 接口的对象）对象。listener 必须是一个实现了 EventListener 接口的对象，或者是一个函数

摘自MDN

我一直都是在listener中传入一个函数，通过监听事件发生来实现一些逻辑。然而看到文档描述中先提到了“一个实现了EventListener接口的对象”通过进一步查看文档了解到，这个对象指的就是一个含有handleEvent方法的对象。

var obj = {
   // ...
    handleEvent: function(event) {
        // ...
        console.log('event', event)
    }
}
document.body.addEventListener('click', obj, false)

当EventListener所注册的事件发生时，该方法就会被调用，同时会有一个event参数传入到方法中。

了解了概念之后就要看这个知识点能为实际开发带来什么好处了

开发中的应用

举个

var obj = {
    a: 1,
    handleEvent: function(event) {
        alert(this.a)
    }
}
document.body.addEventListener('click', obj, false) // 1
document.body.addEventListener('click', obj.handleEvent, false) // undefined

从例子中可以看出，这种绑定obj会影响this的指向。也就是说我们可以利用这种特点，在处理事件时使用obj中的私有属性或方法

再举个

var obj = {
    a: 1,
    handleEvent: function(event) {
        alert(this.a)
    }
}
var anotherHandler = function(event) {
    alert('hello world')
}
document.body.addEventListener('click', obj, false) // 1
setTimeout(function(){
    obj.handleEvent = anotherHandler // hello world
},2000)

从这个例子中可以看出，这种形式的事件绑定，很方便就能动态改变处理事件的逻辑。不需要先remove再add。

写在最后

这种绑定方式的缺点不在于兼容性方面，应该是可读性方面的缺陷。我在看别人的源码时看到这个时非常疑惑（个人水平有限也占一定的原因），直到查阅了资料之后才知道有这样的一种绑定事件的写法。

所以，日常工作开发中要使用这样的写法时，最好确定一下一起开发的小伙伴是不是也清楚这种方式，避免协作时的冲突。

参考

MDN EventListener

MDN EventTarget.addEventListener()

handleEvent与addEventListener

惯例

本篇原文出自 Roy's Blog