Event retargetting in layman's terms?

[trusktr]

Would someone mind explaining what Event retargeting is, and what it's useful for in layman's terms?

[sideshowbarker]

As I understand it, event retargeting is integral to the overall purpose of not exposing anything about the (private) internals of your custom elements. So for any events that originate from a custom element’s shadow DOM subtree, you retarget them to appear to come from your custom element itself (the only public part of however you’ve implemented it). I don’t know what use cases for event retargeting there might be other than that.

[hayatoito]

Let me close this issue.

[trusktr]

@sideshowbarker I kind of understand what you mean, but not how it applies in practice.

@hayatoito @sideshowbarker As an end developer using WebComponents API, how do I actually take advantage of this feature (supposing I have a custom element that contains a direct shadow root)?

[rniwa]

@trusktr : Not sure if this is what you're asking, but you can look at examples of show event's target and relatedTarget are adjusted as the event bubbles up across shadow boundaries in https://trac.webkit.org/browser/trunk/LayoutTests/fast/shadow-dom/event-with-related-target.html

[trusktr]

In all those test the related target is chosen. So, is related target something that the end-developer chooses? Or who/what choses that? I can see what the test cases are doing, but I don't know why we'd want to do that. I'm trying to understand what/why/how retargetting is (not just seeing what it does like in those tests).

Describing a rocket as a device that "burns some flammable liquid" as per what tests show, isn't as helpful as saying a rocket ejects fuel so that while the device is in the air the ejected fuel can push the rocket to a new location.

How does event retargetting effect an end-developer's (end-developer being someone writing an HTML app at the highest level of abstraction) developing experience? What patterns does it allow? What problems does it solve?

(in layman's terms)

[rniwa]

Ah, okay.

So what event re-targeting does is that, it tries to make event.target return a EventTarget (often an instance of Node) which is in the same tree as the current target.

Let's say you dispatched an event inside a shadow tree. Then when the event bubbles out of the shadow tree, it sets the target to its host. This allows the code outside the shadow tree to work as if the shadow tree didn't exist at all.

Without event retargeting, authors need to think about in which tree event.target belongs, and walk up the ancestor chain to find the node which belongs to the same tree as the node the event listener is attached.

[trusktr]

If that's all it's for, then it sounds like end developer don't really need to even worry about it? Because they just apply event listeners on the host or on the light-tree elements that they are explicitly creating.

For example, if you look at the basic components I made in #504 (comment), then if I am the author of the DynamicMenuLayout class, I just add event handlers to the push-pane-layout or those direct motor-node children, without even thinking about how event handling works inside the shadow tree of the push-pane-layout element.

Is that what you mean? That as the component user I only worry about the events in the outer tree of my component (the outer tree, which is that tree that I write myself, while the inner tree is the tree that someone else defined as the shadow tree of the push-pane-layout component)?

TLDR, end users of a component write event handlers as they always did before (if following my same design pattern as in my linked example)?

Seems like this may be more a detail of ShadowDOM implementation than it is anything a final web-stack user should need to really understand. Is there any case in which a Web Component author does need to think about retargeting?

[rniwa]

Yeah, that's the intent of even retargeting; encapsulating the implementation details of components to component users by adjusting event.target.

Some JS frameworks, etc... may need to know the original node from which an event was dispatched to provide fancy inter-component communication / debugging tools. Event.prototype.composedPath() was added for that purpose for example.

[trusktr]

For sure. Thanks! I believe I'll just ignore retargeting for the time being then. :]