168

这是从哪里来的

当我第一次学习 jQuery 时，我通常会附加这样的事件：

$('.my-widget a').click(function() {
    $(this).toggleClass('active');
});

在了解了有关选择器速度和事件委托的更多信息后，我在几个地方读到“jQuery 事件委托将使您的代码更快”。所以我开始写这样的代码：

$('.my-widget').on('click','a',function() {
    $(this).toggleClass('active');
});

这也是复制已弃用的 .live() 事件行为的推荐方法。这对我很重要，因为我的很多网站一直在动态添加/删除小部件。不过，上面的行为与 .live() 并不完全相同，因为只有添加到现有容器 '.my-widget' 的元素才会获得这种行为。如果我在该代码运行后动态添加另一个 html 块，这些元素将不会获得绑定到它们的事件。像这样：

setTimeout(function() {
    $('body').append('<div class="my-widget"><a>Click does nothing</a></div>');
}, 1000);


我想要达到的目标：

  1. .live() 的旧行为 // 意味着将事件附加到尚不存在的元素
  2. .on() 的好处
  3. 绑定事件的最快性能
  4. 管理事件的简单方法

我现在附上这样的所有事件：

$(document).on('click.my-widget-namespace', '.my-widget a', function() {
    $(this).toggleClass('active');
});

这似乎满足了我的所有目标。（是的，由于某种原因，它在 IE 中速度较慢，不知道为什么？）它很快，因为只有一个事件与单个元素相关联，并且仅在事件发生时才评估辅助选择器（如果此处错误，请纠正我）。命名空间很棒，因为它可以更轻松地切换事件侦听器。

我的解决方案/问题

所以我开始认为 jQuery 事件应该总是绑定到 $(document)。
你有什么理由不想这样做吗？
这可以被认为是最佳实践吗？如果不是，为什么？

如果您已经阅读了整篇文章，谢谢。我感谢任何/所有反馈/见解。

假设：

  1. 使用支持.on()// 至少版本 1.7 的jQuery
  2. 您希望将事件添加到动态添加的内容中

读数/示例：

  1. http://24ways.org/2011/your-jquery-now-with-less-suck
  2. http://brandonaaron.net/blog/2010/03/4/event-delegation-with-jquery
  3. http://www.jasonbuckboyer.com/playground/speed/speed.html
  4. http://api.jquery.com/on/
4

4 回答 4

220

不 - 您不应该将所有委托的事件处理程序绑定到document对象。这可能是您可以创建的性能最差的场景。

首先，事件委托并不总是让你的代码更快。在某些情况下，这是有利的，在某些情况下则不是。当您真正需要事件委托并从中受益时，您应该使用事件委托。否则，您应该将事件处理程序直接绑定到事件发生的对象，因为这通常会更有效。

其次，您不应该在文档级别绑定所有委托事件。这正是.live()被弃用的原因，因为当您以这种方式绑定大量事件时，效率非常低。对于委托事件处理，将它们绑定到最近的非动态父级会更有效。

第三，并非所有事件都有效或所有问题都可以通过委派来解决。例如，如果您想拦截输入控件上的键事件并阻止将无效键输入到输入控件中，则不能使用委托事件处理来执行此操作，因为当事件冒泡到委托处理程序时，它已经已由输入控件处理，现在影响该行为为时已晚。

以下是需要或有利的事件委托的时候：

  • 当您捕获事件的对象是动态创建/删除时，您仍然希望在它们上捕获事件，而不必在每次创建新事件处理程序时显式重新绑定事件处理程序。
  • 当您有很多对象都需要完全相同的事件处理程序时（其中很多对象至少有数百个）。在这种情况下，在设置时绑定一个委托事件处理程序可能比绑定数百或更多直接事件处理程序更有效。请注意，委托事件处理在运行时的效率总是低于直接事件处理程序。
  • 当您尝试捕获（在文档中的更高级别）发生在文档中任何元素上的事件时。
  • 当您的设计明确使用事件冒泡和 stopPropagation() 来解决页面中的某些问题或功能时。

要进一步理解这一点，需要了解 jQuery 委托事件处理程序是如何工作的。当你调用这样的东西时：

$("#myParent").on('click', 'button.actionButton', myFn);

#myParent它在对象上安装了一个通用的 jQuery 事件处理程序。当点击事件冒泡到该委托事件处理程序时，jQuery 必须遍历附加到该对象的委托事件处理程序列表，并查看事件的原始元素是否与委托事件处理程序中的任何选择器匹配。

因为选择器可以相当多地涉及，这意味着 jQuery 必须解析每个选择器，然后将其与原始事件目标的特征进行比较，以查看它是否与每个选择器匹配。这不是一个便宜的操作。如果只有其中一个也没什么大不了的，但是如果您将所有选择器放在文档对象上，并且有数百个选择器要与每个冒泡事件进行比较，这可能会严重影响事件处理性能。

出于这个原因，您希望设置您的委托事件处理程序，以便委托事件处理程序尽可能接近目标对象。这意味着更少的事件将通过每个委托的事件处理程序冒泡，从而提高性能。将所有委托事件放在文档对象上是最差的性能，因为所有冒泡事件都必须经过所有委托事件处理程序并针对所有可能的委托事件选择器进行评估。这正是.live()被弃用的原因，因为这就是这样.live()做的，并且被证明是非常低效的。

因此，要实现优化的性能：

  1. 仅当委托事件处理实际提供您需要的功能或提高性能时才使用它。不要总是使用它，因为它很容易，因为当您实际上不需要它时。实际上，它在事件分派时的性能比直接事件绑定更差。
  2. 尽可能将委托的事件处理程序附加到离事件源最近的父级。如果您正在使用委托事件处理，因为您有要为其捕获事件的动态元素，请选择最近的父级，该父级本身不是动态的。
  3. 对委派的事件处理程序使用易于评估的选择器。如果您遵循委托事件处理的工作原理，您将理解委托事件处理程序必须多次与大量对象进行比较，因此选择尽可能高效的选择器或向您的对象添加简单的类以便可以使用更简单的选择器将提高委托事件处理的性能。
于 2012-10-10T17:05:44.247 回答
9

事件委托是一种在元素实际存在于 DOM 之前编写处理程序的技术。此方法有其自身的缺点，只有在您有此类要求时才应使用。

什么时候应该使用事件委托？

  1. 当您为需要相同功能的更多元素绑定通用处理程序时。（例如：表格行悬停）
    • 在示例中，如果您必须使用直接绑定来绑定所有行，您最终会为该表中的 n 行创建 n 个处理程序。通过使用委托方法，您最终可以在 1 个简单的处理程序中处理所有这些。
  2. 当您在 DOM 中更频繁地添加动态内容时（例如：从表中添加/删除行）

为什么不应该使用事件委托？

  1. 与将事件直接绑定到元素相比，事件委托更慢。
    • 它会比较它击中的每个气泡上的目标选择器，比较会很昂贵，因为它很复杂。
  2. 无法控制事件冒泡，直到它碰到它所绑定的元素。

PS：即使对于动态内容，如果在内容插入 DOM 后绑定处理程序，则不必使用事件委托方法。（如果添加的动态内容不经常删除/重新添加）

于 2012-10-10T17:32:20.977 回答
0

显然，现在实际上建议使用事件委托。至少对于香草js。

https://gomakethings.com/why-event-delegation-is-a-better-way-to-listen-for-events-in-vanilla-js/

“Web 性能 # 感觉就像监听文档中的每一次点击都会影响性能，但它实际上比在单个项目上拥有一堆事件监听器更有性能。”

于 2019-07-26T18:40:00.823 回答
0

我想对 jfriend00 的回答添加一些评论和反驳。（主要是基于我的直觉我的意见）

不 - 您不应该将所有委托的事件处理程序绑定到文档对象。这可能是您可以创建的性能最差的场景。

首先，事件委托并不总是让你的代码更快。在某些情况下，这是有利的，在某些情况下则不是。当您真正需要事件委托并从中受益时，您应该使用事件委托。否则，您应该将事件处理程序直接绑定到事件发生的对象，因为这通常会更有效。

虽然如果您只为单个元素注册和事件，性能可能会稍好一些，但我相信它不会与委托带来的可扩展性优势相提并论。我也相信浏览器正在（将会）越来越有效地处理这个问题，尽管我没有证据证明这一点。在我看来，事件委托是要走的路！

其次，您不应该在文档级别绑定所有委托事件。这正是 .live() 被弃用的原因，因为当您有很多以这种方式绑定的事件时，这非常低效。对于委托事件处理，将它们绑定到最近的非动态父级会更有效。

我有点同意这一点。如果您 100% 确定事件只会发生在容器内，那么将事件绑定到该容器是有意义的，但我仍然反对将事件直接绑定到触发元素。

第三，并非所有事件都有效或所有问题都可以通过委派来解决。例如，如果您想拦截输入控件上的键事件并阻止将无效键输入到输入控件中，则不能使用委托事件处理来执行此操作，因为当事件冒泡到委托处理程序时，它已经已由输入控件处理，现在影响该行为为时已晚。

这是不正确的。请看这个codePen：https ://codepen.io/pwkip/pen/jObGmjq

document.addEventListener('keypress', (e) => {
    e.preventDefault();
});

它说明了如何通过在文档上注册 keypress 事件来防止用户键入。

以下是需要或有利的事件委托的时候：

当您捕获事件的对象是动态创建/删除时，您仍然希望在它们上捕获事件，而不必在每次创建新事件处理程序时显式重新绑定事件处理程序。当您有很多对象都需要完全相同的事件处理程序时（其中很多对象至少有数百个）。在这种情况下，在设置时绑定一个委托事件处理程序可能比绑定数百或更多直接事件处理程序更有效。请注意，委托事件处理在运行时的效率总是低于直接事件处理程序。

我想回复来自https://ehsangazar.com/optimizing-javascript-event-listeners-for-performance-e28406ad406c的这句话

Event delegation promotes binding as few DOM event handlers as possible, since each event handler requires memory. For example, let’s say that we have an HTML unordered list we want to bind event handlers to. Instead of binding a click event handler for each list item (which may be hundreds for all we know), we bind one click handler to the parent unordered list itself.

此外，谷歌搜索performance cost of event delegation google返回更多有利于事件委托的结果。

当您尝试捕获（在文档中的更高级别）发生在文档中任何元素上的事件时。当您的设计明确使用事件冒泡和 stopPropagation() 来解决页面中的某些问题或功能时。要进一步理解这一点，需要了解 jQuery 委托事件处理程序是如何工作的。当你调用这样的东西时：

$("#myParent").on('click', 'button.actionButton', myFn); 它在#myParent 对象上安装了一个通用的jQuery 事件处理程序。当点击事件冒泡到该委托事件处理程序时，jQuery 必须遍历附加到该对象的委托事件处理程序列表，并查看事件的原始元素是否与委托事件处理程序中的任何选择器匹配。

因为选择器可以相当多地涉及，这意味着 jQuery 必须解析每个选择器，然后将其与原始事件目标的特征进行比较，以查看它是否与每个选择器匹配。这不是一个便宜的操作。如果只有其中一个也没什么大不了的，但是如果您将所有选择器放在文档对象上，并且有数百个选择器要与每个冒泡事件进行比较，这可能会严重影响事件处理性能。

出于这个原因，您希望设置您的委托事件处理程序，以便委托事件处理程序尽可能接近目标对象。这意味着更少的事件将通过每个委托的事件处理程序冒泡，从而提高性能。将所有委托事件放在文档对象上是最差的性能，因为所有冒泡事件都必须通过所有委托事件处理程序并针对所有可能的委托事件选择器进行评估。这正是 .live() 被弃用的原因，因为这是 .live() 所做的，并且被证明是非常低效的。

这是在哪里记录的？如果这是真的，那么 jQuery 似乎以一种非常低效的方式处理委托，然后我的反驳论点应该只适用于 vanilla JS。

仍然：我想找到支持这一说法的官方消息来源。

：： 编辑 ：：

似乎 jQuery 确实以非常低效的方式进行事件冒泡（因为它们支持 IE8） https://api.jquery.com/on/#event-performance

所以我在这里的大部分论点只适用于 vanilla JS 和现代浏览器。

于 2020-05-01T11:16:11.497 回答