Ada*_*ant 5 javascript events dom-events
在阅读了有关最佳性能 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 == ...) { ... };
})
从技术角度我无法判断这个解决方案有什么问题。有些东西对我来说似乎太重了，它有一种代码的味道。
这在移动设备上会有问题吗？DOM 含量高的本质是否<body>最终对性能造成的损害大于好处？
我没有使用 jQuery，请建议纯 JS 解决方案。
小智 4
在阅读了有关最佳性能 JavaScript 的文章后，我了解到最好尽量减少与 DOM 的交互，并更多地依赖 JavaScript 本身的逻辑。
我不确定这意味着什么。无论它做什么，您是否也阅读过有关何时担心优化的部分（稍后，或永远，或当您确实必须时）？
其中一部分是对元素列表使用单个事件侦听器并读取点击目标，而不是对每个元素使用一个事件侦听器
这是一种最适用于以下情况的模型：您有一百个<li>元素要侦听事件，因此您不必将事件处理程序附加到每个元素，而是将一个事件处理程序附加到<ul>. 就我个人而言，我不相信这样做有这么大的好处，但无论如何，这就是逻辑。
这可能有益的原因有两个：
只有一个事件处理程序占用内存，而不是 100 个。在当今时代，这不太令人信服。
添加新元素时，无需显式向它们添加事件处理程序，因为事件处理程序已在其祖先上就位。这确实可以使程序逻辑更简单。
然而，将其扩展到将一个主事件处理程序放在主体上就太过分了。正如一位评论者提到的，该事件处理程序中的逻辑最终将成为一大堆意大利面条。
一个好的基本规则是将事件处理程序放在所涉及的元素上，或者放在附近的祖先父元素上，以便在多个子元素/后代元素上以相同或相似的方式处理事件。
所以你的“这疯了吗”问题的答案是，是的。