使用原生 JS 实现事件委托

很多人是在使用事件委托的，那对于一个使用者来说，只要能正确的使用好事件委托，完成工作，就算可以了，那么你有认真的考虑过事件委托的原理，以及你的使用场景是否适合使用事件委托呢，如果需要使用事件委托，那么你是否有正确的使用呢？这里我想简单的说一下我对事件委托的理解，希望可以有机会多多交流。

概述

事件委托有哪些好处，才会被现在人们大量的使用呢？

那么就得先说说事件的一些性能和使用的问题：

1：绑定事件越多，浏览器内存占用越大，严重影响性能。

2：ajax的出现，局部刷新的盛行，导致每次加载完，都要重新绑定事件

3：部分浏览器移除元素时，绑定的事件并没有被及时移除，导致的内存泄漏，严重影响性能

4：大部分ajax局部刷新的，只是显示的数据，而操作却是大部分相同的，重复绑定，会导致代码的耦合性过大，严重影响后期的维护。

这些个限制，都是直接给元素事件绑定带来的问题，所以经过了一些前辈的总结试验，也就有了事件委托这个解决方案。

我们本篇将要说的是，事件委托。

如果我们相对一个技术点了解的更深，用的更好，那么我们就需要对这个技术点的原理有更多的了解，那么事件委托的实现原理是什么呢？

1：事件的冒泡，所以才可以在父元素来监听子元素触发的事件。

2：DOM的遍历，一个父级元素包含的子元素过多，那么当一个事件被触发时，是否触发了某一种类型的元素呢？

这是事件委托的两个基础，也是事件委托的核心，跟事件委托相关的技术点，如果碰到什么问题，都可以在这两个点进行切入，来寻求解决方案。

而且还有一点要注意：不管你使用什么样的框架，实现方案，这两个基础都是必须的，OK，我们继续看下去。

只是使用文字描述，是无法很好的理解事件委托的，那么这里我们来看一个例子：

注：假设只支持标准浏览器，不兼容IE的低版本

我现在使用原生的JS，来实现一个简单的事件委托

然后，可以直接这么调用：_delegate(document.body,"item",fn);

它执行的效果是：body内部，所有class包含item的元素，都会相应该操作。

注：该方法是为了说明这个原理，并不是用于生产开发中的，如果想要用在生产开发中，那么实现方式应该更严谨，一些必要的类型检测，还是需要的。