2017-07-19

[译] 事件代理:模式 or 反模式?

原文作者: @Neil Roberts
原文地址: https://www.sitepen.com/blog/2017/07/11/event-delegation-pattern-or-anti-pattern/
译文地址: http://www.wemlion.com/post/event-delegation-pattern-or-anti-pattern
本文由 文蔺 翻译,转载请保留此声明。
著作权属于原作者,本译文仅用于学习、研究和交流目的,请勿用于商业目的。

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

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

事件冒泡与事件代理

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

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

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

假设

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

本机事件注册机制太慢

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

新的原生 API 不会出现

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

不常见用例没有性能损失

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

条件与背景

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

抽象

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

不会发生副作用

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

不受时间影响

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

总结

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

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

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

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

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

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

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