在日常前端开发中，我经常使用 DOM 作为全局事件总线，客户端应用程序的每个部分都可以访问它。
但其中有一个“功能”，在我看来可能被认为是有害的:任何监听器都可以阻止通过此“总线”发出的事件的传播。
所以，我想知道这个功能什么时候有用。让一个听众“禁用”所有其他听众是否明智？如果该听众没有就此类操作做出正确决策所需的所有信息怎么办？
更新
这不是一个关于“什么是冒泡和捕获”的问题，或者“Event.stopPropagation 实际上是如何工作的”。 这是关于“允许任何订阅者影响事件流，这是一个好的解决方案吗”的问题？
最佳答案
当我们想要防止监听器相互干扰时，我们需要(我正在谈论 JS 中当前的用法)stopPropagation()。但是，这不是强制性的。
避免 stopPropagation 的实际原因:
使用它通常意味着您知道代码正在等待同一事件，并干扰当前监听器的操作。如果是这种情况，那么这里可能(见下文)存在设计问题。我们尽量避免在多个不同的地方管理同一件事。
可能有其他监听器正在等待相同类型的事件，同时不会干扰当前监听器的操作。在这种情况下，
stopPropagation()可能会成为问题。
但是假设您在容器元素上放置了一个魔法监听器，每次单击时都会触发该监听器以执行一些魔法。魔术听众只知道魔术，而不了解文档(至少在魔术之前不知道)。它做了一件事。在这种情况下，让它只知道魔法是一个很好的设计选择。
如果有一天您需要防止特定区域中的点击触发此魔法，因为向魔法监听器公开文档特定的区别是不好的，那么明智的做法是防止在其他地方传播。
更好的解决方案可能是(我认为)有一个监听器来决定是否需要调用魔术函数，而不是将魔术函数作为可停止的监听器。这样你就可以保持清晰的逻辑，同时不暴露任何内容。
为订阅者提供(我指的是API设计)影响流量的方式并没有错；这取决于此功能背后的需求。它可能对使用它的开发人员有用。例如，stopPropagation 对于很多人来说过去(现在)非常有用。
某些系统实现了 continueX 方法而不是 stopX。在 JavaScript 中，当被调用者可能执行一些异步处理(例如 AJA* 请求)时，它非常有用。然而，它不适用于 DOM，因为 DOM 需要及时得到结果。我认为 stopPropagation 是 DOM API 的明智设计选择。
关于dom - 为什么我们在 DOM 中需要 event.stopPropagation() ？这是不好的架构模式吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37698246/