【第1016期】事件代理：模式 or 反模式？

前言

终于熬过四个月了，人都黑了一圈。8 月 4 号的早读文章由 @ 文蔺翻译授权分享。

正文从这开始～

JavaScript 工具包（toolkit）和框架所做的大量工作，都集中于尝试修复、规范或优化浏览器的功能实现。此类工作需要做出许多假设，这些假设包括：问题是什么，开发人员将如何使用我们的工具，以及我们对未来的期望。

但这些假设经常是错误的。更有甚者，在很长一段时间内，这些选择可能貌似正确，直至某天我们被问题反咬一口。在这个无知的幸福时期当中，我们的工具包可能变得相当受欢迎，并成为大型复杂代码库的重要组成部分。

事件冒泡与事件代理

事件冒泡允许源自子节点的事件向父级节点“冒泡”（bubble）。这种行为导致 JavaScript 开发者使用松散的设计模式来识别我们所关心的接收事件的节点 —— 通常使用 CSS 选择器 —— 同时将事件监听器添加到该节点的父级节点上。

一旦这种模式进入工具包之中，设计 API 时须做出一些假设。在开始阶段，这些假设主要围绕性能与效率展开。

事件代理（Event Delegation）是处理事件的实际方法之一。然而，这种方法论适用于所有项目吗？实际上，更好的问题可能是，每个工具包的所基于的假设是否与你的项目需求相符。要想知道某个 API 是否适合当下项目，就要了解这些工具是建立在哪些假设之上的，并且理解每个工具包如何解释它们。

假设

一起来看看，在思考如何有效管理 DOM 事件时可能会产生的一些假设。

本机事件注册机制太慢

在你能够提出 API 存在的继发原因之前，不要创建新的 API。随着浏览器厂商们对运行时的投入增加，你的功能实现总有一天会比原生实现慢。我所在的 SitePen 有一个项目依赖于数组拼接（splice）速度。我们发现，在某些情况下，手动操作索引和数组长度能够带来显著的性能提升。但我们无法定位到特定浏览器、浏览器版本或平台，因为无法进行运行时功能测试以确定我们的实现是否比原生 API 快。

新的原生 API 不会出现

保持谨慎，确保已收集到足够的信息，可以降级使用原生实现 —— 无论是已存在的，还是理想情况下可能存在的。这项工作的另一个名字叫“预防过时”（future proofing）。在某些情况下，你可能会使用必需参数超出绝对需要的 API，但如果它l能够保证轻松地过渡到更优秀的原生 API，那么完全可以如此。一个很好的例子是最终获得原生支持的 querySelectorAll API，之前许多开发人员假设这种事永远不会发生。

不常见用例没有性能损失

事件代理可能会以数种方式呈现。例如两种特殊情况：大量节点上的少量事件，以及少数节点上的大量事件。如果针对其中之一进行优化，则可能会为另一个带来明显的瓶颈。虽然使用事件代理可能只需要向单个节点添加一个事件侦听器，但识别触发回调的节点的复杂方法对性能的影响可能不成比例。快速触发大量事件（例如鼠标移动或滚动事件）正是使用事件代理的场景。

条件与背景

在考虑事件代理时，很容易认为我们只需要关心用户交互。这可能导致我们假设节点始终是文档的一部分，然后开始思考，为何不在 document 对象上添加单个事件处理程序呢？DOM 事件并非总是用户交互的结果 —— 我们也有人为事件、自定义事件以及加载事件等。如果想要监听的节点不在文档中，而监听器却绑定在 document 对象上，我们永远得不到通知。如果在 API 中无法区别监听器是添加到 document 上，抑或是添加到我们所传递的参数上，则能够理解为什么会出现这种情况。

抽象

如果一个工具包提供一个仅用于支持代理的事件处理 API —— 需要父级节点和标识子节点的选择器 —— 则无法将事件监听器直接添加到某个节点。即使是使用 CSS 选择器，也引入了更高级的功能，可以轻松地使用另一种选择器语法或简单函数。

不会发生副作用

如上所述，DOM 事件冒泡是事件代理模式存在的前提。但是了解完整规范所涉及的内容之后，你会发现，事件冒泡是可以取消的。你的实现可能会将 stopPropagation 方法为空函数的自定义事件传递给回调函数；或者，你可能只会记录问题，并限制事件代理 API 的使用。这两种方法都有问题，但是如果你打算像为 document 对象事件处理程序那样工作，添加大量可取消的事件层可能放大副作用。

不受时间影响

一旦代码编写完成，很可能就会弃而不顾。但浏览器正在以我们无法想象、预测的方式向前发展，我们在编写代码时所做的假设可能会被证明是错误的，尽管我们尽了最大的努力。

总结

为什么要在项目中使用事件代理？

原生实现太慢了吗？对现代浏览器来说不太可能。

是否有更好的 API 来执行事件代理？目前还没有 —— 如果你需要事件代理，这是一个很好的模式。

该工具包的性能优化是否符合项目需求？如果它专注于特殊情况，可能不会。

工具包的实现中有没有什么不适用于你的项目的内容？阅读文档，这些通常都会标出。

是否有副作用？遇到错误前你可能不会发现这一点，所以要特别注意。

人们在不了解创作假设的情况下，所有设计模式都有成为反模式的风险，所以对项目中使用的任何新工具都应当回答同样的问题。如果你所做的似乎是在抄近路，要特别小心。谨慎、多加思考，才能使项目发光。

关于本文

译者:@文蔺
译文:http://www.wemlion.com/2017/event-delegation-pattern-or-anti-pattern/
作者:@Neil Roberts
原文:https://www.sitepen.com/blog/2017/07/11/event-delegation-pattern-or-anti-pattern/