將大量元素事件偵聽器委托給 document.body 是不是很瘋狂？

Question

在閱讀了性能最佳的 JavaScript 之后，我了解到最好盡量減少與 DOM 的交互，並更多地依賴 JavaScript 本身的邏輯。

其中一部分是對元素列表使用單個事件偵聽器並讀取點擊目標，而不是為每個元素使用一個事件偵聽器

ul#menu
  li#one One
  li#two Two
  li#three Three

$ul = document.getElementById('#menu')
$ul.addEventListener('click', function(e) {
  if (e.target.id == ...) { ... } // You get the idea
})

我有一個網站，有幾個導航欄、幾個下拉按鈕等。 那么為什么不在主體上創建一個事件偵聽器並只查看事件目標呢？

document.body.addEventListener('click', function(e) {
  if (e.target.id == ...) { ... };
})

從技術角度來看，我無法判斷此解決方案有什么問題。 有些東西對我來說似乎太重了，它有一種代碼味道。

這在手機上會不會有問題？ <body>在 DOM 中處於高位的性質最終對性能造成的損害大於好處嗎？

我沒有使用 jQuery ，請建議純 JS 解決方案。

Answer 1

在閱讀了性能最佳的 JavaScript 之后，我了解到最好盡量減少與 DOM 的交互，並更多地依賴 JavaScript 本身的邏輯。

我不確定這意味着什么。 不管它做什么，您是否還閱讀了有關何時擔心優化的部分（稍后，或永遠，或當您真的需要時）？

其中一部分是對元素列表使用單個事件偵聽器並讀取點擊目標，而不是為每個元素使用一個事件偵聽器

這是一種模型，最適用於例如您有一百個<li>元素來監聽事件的情況，因此，您無需將事件處理程序附加到每個元素，而是將一個事件處理程序附加到<ul> 。 就個人而言，我不相信這樣做有這么大的好處，但無論如何這是邏輯。

這可能是有益的，有兩個原因：

只有一個事件處理程序占用內存，而不是 100 個。在這個時代，這不太令人信服。
添加新元素時，無需顯式向它們添加事件處理程序，因為事件處理程序已在其祖先上到位。 這確實可以使程序邏輯更簡單。

但是，將其擴展到在主體上放置一個主事件處理程序太過分了。 正如一位評論者所提到的，該事件處理程序中的邏輯最終將成為一大堆意大利面條。

一個好的基本規則是將事件處理程序放在所涉及的元素上，或者放在附近的祖先父元素上，以便在多個子/后代上以相同或相似的方式處理事件。

所以你的“是不是瘋了”的問題的答案是，是的。

Answer 2

為什么你會想要優化這樣的東西？ 與單個背景圖像的內存占用或應用程序永遠不會使用的大量 JQuery 事物相比，這簡直是小菜一碟。 至於 CPU 使用率，則以每小時微秒為單位。 我非常懷疑您的主要性能問題將來自那里。

分解代碼在任何地方都是一樣的，無論是在 JavaScript 事件處理程序、OpenGL 着色器還是 c++ 模板中。 當它被證明比重新編寫相同代碼的微小變化更有用或更方便時，你就會這樣做。

不過，您可能也想這樣做，因為您的老板告訴過您，或者一些有影響力的混蛋將其命名為“良好做法”。

將大量元素事件偵聽器委托給 document.body 是不是很瘋狂？

問題描述

2 個解決方案

解決方案1
4

解決方案2
0 2014-10-31 13:06:09

將大量元素事件偵聽器委托給 document.body 是不是很瘋狂？

問題描述

2 個解決方案

解決方案1 4

解決方案2 0 2014-10-31 13:06:09

解決方案1
4

解決方案2
0 2014-10-31 13:06:09