在綁定中我們知道：
事件信息都存儲在數(shù)據(jù)緩存中，對于沒有特殊事件特有監(jiān)聽方法和普通事件都用 addEventListener 來添加事件了，而特有監(jiān)聽方法的特殊事件則用了另一種方式來添加事件，通過 addEventListener 觸發(fā)事件后回調(diào)句柄如何處理？
具體來說就是，如何委派事件的，用到哪些機(jī)制，我們?nèi)绻玫巾?xiàng)目上是否能借鑒？我們先深入測試下，W3C下面事件執(zhí)行是順序，假如每一個(gè)節(jié)點(diǎn)都綁定了事件，那么事件的觸發(fā)順序如下。
我們通過測試右邊的案例，來總結(jié)下事件執(zhí)行的規(guī)律。
由此可見：
默認(rèn)的觸發(fā)循序是從事件源目標(biāo)元素也就是 event.target 指定的元素，一直往上冒泡到 document 或者 body，途經(jīng)的元素上如果有對應(yīng)的事件都會(huì)被依次觸發(fā)
最后得到的結(jié)論：
元素本身綁定事件的順序處理機(jī)制。
分幾種情況：
假設(shè)綁定事件元素本身是 A，委派元素 B.C。
第一種：
A,B,C各自綁定事件，事件按照節(jié)點(diǎn)的冒泡層次觸發(fā)
第二種：
元素 A 本身有事件，元素還需要委派元素 B.C 事件 委派的元素 B.C 肯定是該元素 A 內(nèi)部的，所以先處理內(nèi)部的委派，最后處理本身的事件
第三種：
元素本身有事件，元素還需要委派事件，內(nèi)部委派的元素還有自己的事件，這個(gè)有點(diǎn)繞 先執(zhí)行 B,C 自己本身的事件，然后處理 B,C 委派的事件，最后處理 A 事件
為什么需要了解這個(gè)處理的順序呢？ 因?yàn)閖Query做委托排序的時(shí)候要用到。
請驗(yàn)證，完成請求
由于請求次數(shù)過多，請先驗(yàn)證，完成再次請求
打開微信掃碼自動(dòng)綁定
綁定后可得到
使用 Ctrl+D 可將課程添加到書簽
舉報(bào)