Back to basics是一系列的小帖子，我在其中解釋了我在項目中一直使用的基本的、無依賴的web技術(shù)。這些都不是什么啟示，但是這些年來幫助我建立了牢固的，容易維護的項目。

在構(gòu)建web接口時，我最喜歡的一個技巧是事件委托

事件不僅僅發(fā)生在應(yīng)用它們的元素上。相反，它們沿著DOM樹一直到事件，然后再返回。事件生命周期的這些階段稱為事件冒泡和事件捕獲。

這樣做的實際結(jié)果是，您不需要對文檔中的每個元素應(yīng)用事件處理程序。相反，通常父元素上的一個處理程序就足夠了。在很久以前，這是非常重要的，因為老的瀏覽器經(jīng)常有與事件處理有關(guān)的內(nèi)存泄漏。

假設(shè)你有一個鏈接列表，而不是遵循這些鏈接，你想做一些代碼時，用戶點擊他們:

這是可行的，但有兩個問題:

1. 當列表的內(nèi)容發(fā)生更改時，您需要重新索引該列表(如再次調(diào)用assignhandlers())

2. 您只對被單擊的鏈接作出反應(yīng)，如果您還想在單擊列表項時執(zhí)行某些操作，則需要分配更多的處理程序。

你可以試著在這個例子中點擊“切換更多的狗”按鈕。它向列表中添加更多項目，當您單擊它們時，什么也不會發(fā)生。

您可以嘗試這里的事件委托示例，代碼可以在GitHub (event- delegate .html)上找到。如果你現(xiàn)在點擊“切換更多的狗”按鈕，并點擊任何小狗的鏈接，你會看到它仍然工作。

您可以做一些事情來確定單擊事件發(fā)生在哪個元素上。這里最重要的部分是“let t = e.target;”行，它存儲了當前由事件捕獲/冒泡循環(huán)報告的元素。如果我想對一個鏈接做出反應(yīng)，我將檢查目標上是否存在一個“href”。如果我想對列表項做出反應(yīng)，我將' nodeName '與' LI '進行比較。注意，如果進行這種檢查，節(jié)點名總是大寫的。

我真的很喜歡事件委托，因為它給了我更多的靈活性，而且我不必擔心內(nèi)容的變化。處理者只是躺在那里等待，直到需要它。