何时在 Web 组件上下文中使用事件冒泡

Question

我了解事件冒泡的技术使用（方法）。我无法得到好的答案是何时使用事件冒泡，尤其是在 Web 组件的上下文中。

一般来说，一些默认的浏览器事件会冒泡，因为点击事件是有意义的，因为点击一个孩子也是点击包含父级。

对于某些仅适用于子元素的特定事件，不让事件冒泡以使 API 更清晰是有意义的，因为冒泡的事件成为包含组件的 API 的一部分（？）

例如带有事件冒泡的元素结构：https://lit.dev/playground/#gist=2554194ca19abd3915cf6b4779189f6c

冒泡的优点：

• 在更高级别附加事件处理程序的代码更少
• 对于 API 消费者来说不太清楚（除非正确记录），因为冒泡的事件成为包含元素的 API 的一部分
• ...

缺点：

• 事件必须在更高级别需要时从包含元素中重新调度
• 如果没有正确记录并且没有检查事件的来源，API 可能会变得模糊。
• ...

所以我的问题是：

• 对我来说，我想让 API 尽可能明确，这样就不会冒泡，还有什么意见/想法吗？

• 我在这里阅读了更多信息（https://open-wc.org/guides/knowledge/events/），但是还有更多最佳实践或需要考虑的事情吗？

Answer 1

你列出了几乎所有的优点和缺点。根据我的经验，非常小心和有目的地使用冒泡。它很快就会失控。给你举个例子。

假设您向下拉元素添加冒泡

close

事件。相当常见。您这样做是为了通知外界该元素已关闭。它甚至可以在父类中定义以供一般使用。在将此元素放入自定义对话框之前，一切正常。事实证明，对话框在处理

close

事件时会关闭叠加层。由于下拉列表会调度此事件，因此对话框将在下拉列表关闭时关闭。

这是使用冒泡事件的意外后果的示例。这可能是一个容易修复的错误，但是当您的应用程序增长并且您的组件基础增长时，进行这些更改变得更加困难。

我最近写了一个 UI 组件库，我决定所有事件都是非冒泡的，除非它们真的必须与整个 DOM 进行通信。这几乎从不。事件重定向不是什么大问题，但这样做可以节省您解决与冒泡不起作用的边缘情况相关的问题的时间。