起因:
1、這是前端面試的經典題型,要去找工作的小夥伴看看還是有幫助的;
2、其實我一直都沒弄明白,寫這個一是為了備忘,二是給其他的知其然不知其是以然的小夥伴們以參考;
概述:
那什麼叫事件委托呢?它還有一個名字叫事件代理,JavaScript進階程式設計上講:事件委托就是利用事件冒泡,隻指定一個事件處理程式,就可以管理某一類型的所有事件。那這是什麼意思呢?網上的各位大牛們講事件委托基本上都用了同一個例子,就是取快遞來解釋這個現象,我仔細揣摩了一下,這個例子還真是恰當,我就不去想别的例子來解釋了,借花獻佛,我摘過來,大家認真領會一下事件委托到底是一個什麼原理:
有三個同僚預計會在周一收到快遞。為簽收快遞,有兩種辦法:一是三個人在公司門口等快遞;二是委托給前台MM代為簽收。現實當中,我們大都采用委托的方案(公司也不會容忍那麼多員工站在門口就為了等快遞)。前台MM收到快遞後,她會判斷收件人是誰,然後按照收件人的要求簽收,甚至代為付款。這種方案還有一個優勢,那就是即使公司裡來了新員工(不管多少),前台MM也會在收到寄給新員工的快遞後核實并代為簽收。
這裡其實還有2層意思的:
第一,現在委托前台的同僚是可以代為簽收的,即程式中的現有的dom節點是有事件的;
第二,新員工也是可以被前台MM代為簽收的,即程式中新添加的dom節點也是有事件的。
為什麼要用事件委托:
一般來說,dom需要有事件處理程式,我們都會直接給它設事件處理程式就好了,那如果是很多的dom需要添加事件處理呢?比如我們有100個li,每個li都有相同的click點選事件,可能我們會用for循環的方法,來周遊所有的li,然後給它們添加事件,那這麼做會存在什麼影響呢?
在JavaScript中,添加到頁面上的事件處理程式數量将直接關系到頁面的整體運作性能,因為需要不斷的與dom節點進行互動,通路dom的次數越多,引起浏覽器重繪與重排的次數也就越多,就會延長整個頁面的互動就緒時間,這就是為什麼性能優化的主要思想之一就是減少DOM操作的原因;如果要用事件委托,就會将所有的操作放到js程式裡面,與dom的操作就隻需要互動一次,這樣就能大大的減少與dom的互動次數,提高性能;
每個函數都是一個對象,是對象就會占用記憶體,對象越多,記憶體占用率就越大,自然性能就越差了(記憶體不夠用,是硬傷,哈哈),比如上面的100個li,就要占用100個記憶體空間,如果是1000個,10000個呢,那隻能說呵呵了,如果用事件委托,那麼我們就可以隻對它的父級(如果隻有一個父級)這一個對象進行操作,這樣我們就需要一個記憶體空間就夠了,是不是省了很多,自然性能就會更好。
事件委托的原理:
事件委托是利用事件的冒泡原理來實作的,何為事件冒泡呢?就是事件從最深的節點開始,然後逐漸向上傳播事件,舉個例子:頁面上有這麼一個節點樹,div>ul>li>a;比如給最裡面的a加一個click點選事件,那麼這個事件就會一層一層的往外執行,執行順序a>li>ul>div,有這樣一個機制,那麼我們給最外面的div加點選事件,那麼裡面的ul,li,a做點選事件的時候,都會冒泡到最外層的div上,是以都會觸發,這就是事件委托,委托它們父級代為執行事件。
事件委托怎麼實作:
終于到了本文的核心部分了,哈哈,在介紹事件委托的方法之前,我們先來看一段一般方法的例子:
子節點實作相同的功能:
1 2 3 4 5 6 | |
實作功能是點選li,彈出123:
1 2 3 4 5 6 7 8 9 | |
上面的代碼的意思很簡單,相信很多人都是這麼實作的,我們看看有多少次的dom操作,首先要找到ul,然後周遊li,然後點選li的時候,又要找一次目标的li的位置,才能執行最後的操作,每次點選都要找一次li;
那麼我們用事件委托的方式做又會怎麼樣呢?
1 2 3 4 5 6 | |
這裡用父級ul做事件處理,當li被點選時,由于冒泡原理,事件就會冒泡到ul上,因為ul上有點選事件,是以事件就會觸發,當然,這裡當點選ul的時候,也是會觸發的,那麼問題就來了,如果我想讓事件代理的效果跟直接給節點的事件效果一樣怎麼辦,比如說隻有點選li才會觸發,不怕,我們有絕招:
Event對象提供了一個屬性叫target,可以傳回事件的目标節點,我們成為事件源,也就是說,target就可以表示為目前的事件操作的dom,但是不是真正操作dom,當然,這個是有相容性的,标準浏覽器用ev.target,IE浏覽器用event.srcElement,此時隻是擷取了目前節點的位置,并不知道是什麼節點名稱,這裡我們用nodeName來擷取具體是什麼标簽名,這個傳回的是一個大寫的,我們需要轉成小寫再做比較(習慣問題):
1 2 3 4 5 6 7 8 9 10 11 | |
這樣改下就隻有點選li會觸發事件了,且每次隻執行一次dom操作,如果li數量很多的話,将大大減少dom的操作,優化的性能可想而知!
上面的例子是說li操作的是同樣的效果,要是每個li被點選的效果都不一樣,那麼用事件委托還有用嗎?
1 2 3 4 5 6 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | |
上面實作的效果我就不多說了,很簡單,4個按鈕,點選每一個做不同的操作,那麼至少需要4次dom操作,如果用事件委托,能進行優化嗎?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |
用事件委托就可以隻用一次dom操作就能完成所有的效果,比上面的性能肯定是要好一些的
現在講的都是document加載完成的現有dom節點下的操作,那麼如果是新增的節點,新增的節點會有事件嗎?也就是說,一個新員工來了,他能收到快遞嗎?
看一下正常的添加節點的方法:
1 2 3 4 5 6 7 | |
現在是移入li,li變紅,移出li,li變白,這麼一個效果,然後點選按鈕,可以向ul中添加一個li子節點
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | |
這是一般的做法,但是你會發現,新增的li是沒有事件的,說明添加子節點的時候,事件沒有一起添加進去,這不是我們想要的結果,那怎麼做呢?一般的解決方案會是這樣,将for循環用一個函數包起來,命名為mHover,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | |
雖然功能實作了,看着還挺好,但實際上無疑是又增加了一個dom操作,在優化性能方面是不可取的,那麼有事件委托的方式,能做到優化嗎?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | |
看,上面是用事件委托的方式,新添加的子元素是帶有事件效果的,我們可以發現,當用事件委托的時候,根本就不需要去周遊元素的子節點,隻需要給父級元素添加事件就好了,其他的都是在js裡面的執行,這樣可以大大的減少dom操作,這才是事件委托的精髓所在。
現在給一個場景 ul > li > div > p,div占滿li,p占滿div,還是給ul綁定時間,需要判斷點選的是不是li(假設li裡面的結構是不固定的),那麼e.target就可能是p,也有可能是div,這種情況你會怎麼處理呢?
那我們現在就再現一下他給的場景
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
如上清單,有4個li,裡面的内容各不相同,點選li,event對象肯定是目前點選的對象,怎麼指定到li上,下面我直接給解決方案:
1 2 3 4 5 6 7 8 9 10 11 | |
核心代碼是while循環部分,實際上就是一個遞歸調用,你也可以寫成一個函數,用遞歸的方法來調用,同時用到冒泡的原理,從裡往外冒泡,知道currentTarget為止,當目前的target是li的時候,就可以執行對應的事件了,然後終止循環,恩,沒毛病!
這裡看不到效果,大家可以複制過去運作一下!
總結:
那什麼樣的事件可以用事件委托,什麼樣的事件不可以用呢?
适合用事件委托的事件:click,mousedown,mouseup,keydown,keyup,keypress。click,down, up,press
值得注意的是,mouseover和mouseout雖然也有事件冒泡,但是處理它們的時候需要特别的注意,因為需要經常計算它們的位置,處理起來不太容易。
不适合的就有很多了,舉個例子,mousemove,每次都要計算它的位置,非常不好把控,在不如說focus,blur之類的,本身就沒用冒泡的特性,自然就不能用事件委托了。