为什么我们在 DOM 中需要 event.stopPropagation()?它是糟糕的架构模式吗? [英] Why do we need event.stopPropagation() in DOM? Is it bad architectural pattern?
问题描述
在日常前端开发中，我经常使用 DOM 作为全局事件总线，客户端应用程序的每个部分都可以访问它.
In the everyday front-end development I often use DOM as a global event bus that is accessible to every part of my client-side application.
但在我看来，其中有一个特性"可以被认为是有害的:任何侦听器都可以阻止传播通过此总线"发出的事件.
But there is one "feature" in it, that can be considered harmful, in my opinion: any listener can prevent propagation of an event emitted via this "bus".
所以，我想知道，这个功能什么时候有用.允许一个听众禁用"所有其他听众是否明智?如果该听众不具备对此类行动做出正确决定所需的所有信息怎么办?
So, I'm wondering, when this feature can be helpful. Is it wise to allow one listener to "disable" all the other? What if that listener does not have all information needed to make right decision about such action?
更新
这不是关于什么是冒泡和捕获"或Event.stopPropagation 实际如何工作"的问题.这是关于允许任何订阅者影响事件流的好解决方案"的问题吗?
This is not a question about "what is bubbling and capturing", or "how Event.stopPropagation actually works". This is question about "Is this good solution, to allow any subscriber to affect an event flow"?
推荐答案
我们需要(我说的是当前在 JS 中的用法)stopPropagation() 当我们想要防止监听器相互干扰时.但是，这不是强制性的.
We need (I am talking about current usage in JS) stopPropagation() when we want to prevent listeners to interfere with each other. However, it is not mandatory to do so.
避免stopPropagation的实际原因:
使用它通常意味着您知道代码在等待相同的事件，并干扰当前侦听器的工作.如果是这种情况，那么可能(见下文)这里存在设计问题.我们尽量避免在多个不同的地方管理同一件事.
Using it usually means that you are aware of code waiting for the same event, and interfering with what the current listener does. If it is the case, then there may (see below) be a design problem here. We try to avoid managing a single thing at multiple different places.
可能有其他监听器在等待相同类型的事件，而不会干扰当前监听器的工作.在这种情况下，stopPropagation() 可能会成为问题.
There may be other listeners waiting for the same type of event, while not interfering with what the current listener does. In this case, stopPropagation() may become a problem.
但是，假设您在容器元素上放置了一个魔术监听器，每次点击都会触发以执行一些魔术.魔术听众只知道魔术，而不知道文档(至少在魔术之前不知道).它做一件事.在这种情况下，让它只知道魔法是一个很好的设计选择.
But let's say that you put a magic listener on a container-element, fired on every click to perform some magic. The magic listener only knows about magic, not about the document (at least not before its magic). It does one thing. In this case, it is a good design choice to leave it knowing only magic.
如果有一天您需要阻止特定区域中的点击触发这种魔法，因为将特定于文档的区别暴露给魔法侦听器是不好的，那么防止在其他地方传播是明智的.
If one day you need to prevent clicks in a particular zone from firing this magic, as it is bad to expose document-specific distinctions to the magic listener, then it is wise to prevent propagation elsewhere.
一个更好的解决方案可能是(我认为)有一个监听器来决定它是否需要调用魔术函数，而不是魔术函数是一个可停止的监听器.这样一来，您就可以保持清晰的逻辑，而不会暴露任何内容.
An even better solution though might be (I think) to have a single listener which decides if it needs to call the magic function or not, instead of the magic function being a stoppable listener. This way you keep a clean logic while exposing nothing.
提供(我说的是API设计)订阅者影响流量的方式没有错；这取决于此功能的需求.它可能对使用它的开发人员有用.例如，stopPropagation 已经(并且现在)对很多人非常有用.
To provide (I am talking about API design) a way for subscribers to affect the flow is not wrong; it depends on the needs behing this feature. It might be useful to the developers using it. For example, stopPropagation has been (and is) quite useful for lots of people.
一些系统实现了 continueX 方法而不是 stopX.在 JavaScript 中，当被调用者可能执行一些异步处理(如 AJA* 请求)时，它非常有用.但是，它不适用于 DOM，因为 DOM 需要及时的结果.我认为 stopPropagation 是 DOM API 的明智设计选择.
Some systems implement a continueX method instead of stopX. In JavaScript, it is very useful when the callees may perform some asynchronous processing like an AJA* request. However, it is not appliable to the DOM, as the DOM needs results in time. I see stopPropagation as a clever design choice for the DOM API.
这篇关于为什么我们在 DOM 中需要 event.stopPropagation()?它是糟糕的架构模式吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
