3 ms·

I completely agree. stopPropagation() should be used only as a last resort. I have removed a lot of unneeded use cases with this task, but because of the size o

I completely agree. stopPropagation() should be used only as a last resort. I have removed a lot of unneeded use cases with this task, but because of the size of our codebase, many still remain. But at least now they include a comment as to why they exist :) With enums/static variables are you referring to custom events or also DOM events? For custom-based events we use that approach but not for DOM events. If you do use it for DOM events, I'm curious to know more about it. Thank you!

noduerme 4y ago
I should clarify that I still use jQuery in most apps, specifically for its namespaced, off-DOM event model. (I've got my own vanilla version that deals in abortcontrollers but jQuery is handy enough for other things that I end up using it anyway). So with native events, I don't bother to write enums but I do namespace them and listen for them through the JQ event chain. With custom events I write the enums and listen for them through JQ on the component instance, without having to listen on window or make the component extend EventTarget. tl;dr I only use custom or namespaced events and never run anything between components/controllers through the DOM's native event chain.
wruza 4y ago
stopPropagation() should be used only as a last resort Why? This way you switch from “an event finds its deepest control” mentality to “anything at these coords receives it”, which may have much broader effect under different situations than any reasonable sense may suggest. Is there any programming benefit except pleasing some hacky techniques which go against the fundamental idea?
- throwaway290 4y ago
  Anything at given coords should receive the event. Whether it makes sense for some other component to receive the event shouldn't be your component's concern. It introduces extra coupling and is inconsiderate to other potential users of the component, since you don't know how everything composes in the end. Any parent listening can always inspect which particular child triggered the event and decide whether to act based on that, but you can't conjure an event once it's gone or stopped propagating.
  - wruza 4y ago
    I agree with your reasoning mostly, and can remember situations when I wanted to make an event shoot through a finished element but couldn’t, at least not easily (it wasn’t web). But I think that it wasn’t a great idea either to make it the default and burden a programmer with this decision in each handler. The current way of doing it is pretty error-prone and bloats each handler with checks which are otherwise mostly pointless or tedious. This incentivizes non-experts to omit that part and just cargo in stopPropagation() calls anyway.

noduerme 4y ago

I should clarify that I still use jQuery in most apps, specifically for its namespaced, off-DOM event model. (I've got my own vanilla version that deals in abortcontrollers but jQuery is handy enough for other things that I end up using it anyway). So with native events, I don't bother to write enums but I do namespace them and listen for them through the JQ event chain. With custom events I write the enums and listen for them through JQ on the component instance, without having to listen on window or make the component extend EventTarget. tl;dr I only use custom or namespaced events and never run anything between components/controllers through the DOM's native event chain.

wruza 4y ago

stopPropagation() should be used only as a last resort Why? This way you switch from “an event finds its deepest control” mentality to “anything at these coords receives it”, which may have much broader effect under different situations than any reasonable sense may suggest. Is there any programming benefit except pleasing some hacky techniques which go against the fundamental idea?

throwaway290 4y ago
Anything at given coords should receive the event. Whether it makes sense for some other component to receive the event shouldn't be your component's concern. It introduces extra coupling and is inconsiderate to other potential users of the component, since you don't know how everything composes in the end. Any parent listening can always inspect which particular child triggered the event and decide whether to act based on that, but you can't conjure an event once it's gone or stopped propagating.
- wruza 4y ago
  I agree with your reasoning mostly, and can remember situations when I wanted to make an event shoot through a finished element but couldn’t, at least not easily (it wasn’t web). But I think that it wasn’t a great idea either to make it the default and burden a programmer with this decision in each handler. The current way of doing it is pretty error-prone and bloats each handler with checks which are otherwise mostly pointless or tedious. This incentivizes non-experts to omit that part and just cargo in stopPropagation() calls anyway.