深入分析Javascript事件代理(深入分析的成语)

编辑：rootadmin

推荐整理分享深入分析Javascript事件代理(深入分析的成语)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:对存在的问题进行了深入分析,深入分析博腾股份,深入分析原因,找出问题根源并有效破解,对存在的问题进行了深入分析,对存在的问题进行了深入分析,深入分析原因,找出问题根源并有效破解,深入分析原因,找出症结,深入分析形势,找准,内容如对您有帮助，希望把文章链接给更多的朋友！

很久很久以来，总感觉事件发生与事件代理到之间没什么鸟区别。

最近，又看了一下，感觉区别其实真不大！看怎么理解吧。

要搞清楚什么是事件代理，就需要先搞清楚什么是代理。

从商业角度来讲，代理就是：我有货，你没货，但丫我没时间、没精力全部卖掉，而你一天闲的蛋疼，只剩下时间了。于是，我委托你帮我买，然后哥给你提成。这个过程中，你实际上相当于也有了货。

OK，怎么从字面来理解事件代理一词的含义？后文有讲。

一先看一个真实的，新手绑定onclik事件的例子

如果按照之前的我，我会怎么给每一个li标签，添加onlick呢？废话，要是我，肯定简单粗暴。循环每一个li，然后全部绑定onlick。

于是我的代码应该是这样子：

好像看起来没问题了。虽然，有些文章说这样很消耗性能，但是，我丫电脑好，老子管你性能，不能太认真。

二突然有一天，我发现通过js添加进来的新的li，没有绑定onlcik

然后，点击maomaoliang,它并没有绑定我的onlick，这是为什么？哦，原来，我原有的li跟我后面生成的li根本不是同时发生的，在创建新的li元素之前，已经给存在的li加事件了。好吧，好烦啊。

三那怎么破？

然后，又好（无）奇（奈）的看了一些文章，原来有个叫事件代理的东西可以用。我就试试看吧！于是改写了部分代码，像这样：

结果，点击新的li，居然也触发了fn函数。好吧，身为一个好奇心驱动的肉身，我怎么能不求甚解呢？还是要踏实点，搞清楚这其中的奥秘才行。

于是，看了事件代理的资料。

首先，要知道什么是事件冒泡：当一个元素上的事件被触发的时候，比如说鼠标点击了一个按钮，同样的事件将会在那个元素的所有祖先元素中被触发。这一过程被称为事件冒泡。

然后，再回到之前的问题“怎么从字面来理解事件代理一词的含义”，谁代理了事件？或者事件代理了谁？以本文的例子来讲，看看改动后的代码，我把onlick事件绑定到了ul标签上面，而不是li标签。于是，当我点击任何一个li标签（不管是动态生成的还是之前就有的）是，这个事件就像泡泡一样，冒啊冒。正常的情况下，ul也会绑定onclick，body也会绑定到onclick，也就说它会冒泡到最根层的元素。但我这里给ul绑定了onlick，那么这时，ul会把泡泡截住，事件也就停止上升，无法抵达body标签。

接着， var target = ev.target || ev.srcElement;这一句话，相当于告诉了我，我究竟点的是谁，谁才是target。如果，这个target刚刚好就是li标签if (target.nodeName.toLowerCase() == 'li')，那么执行fn函数。

最后，我骄傲的回答了那个问题：table代理了onlick事件！

四回忆一下事件代理的步骤

父元素绑定事件父元素知道事件的实际发生目标是谁我们要对目标进行判断，如果是我们需要的元素，则发生回调函数（所以要学好选择器的使用）

五最后总结，事件代理两大好处

性能不小心得到了优化动态添加的元素也能绑定事件了

六需要注意的一点是

上述针对的是原生js事件绑定来讲的，如果你用到了jquery。并把代码改成了如下的样子：

这样一来，新添加的li标签，也能绑click，是不是很方便、很简单，是不是感觉学js没什么卵用。

哈哈，这样想很正常，我以前也这么想，但是，做了一些东西之后，发现jquery还真的不够用了！但是基本够用！

虽然，大神们都说要学js，但我还是觉得可以先学jquery，之后再学js，效果也可以的。

实现高性能JavaScript之执行与加载浏览器在处理HTML页面渲染和JavaScript脚本执行的时候是单一进程的,所以在当浏览器在渲染HTML遇到了script标签会先去执行标签内的代码(如果是使用src属性