on:* attribute to delegate all events

[btakita]

An on: attribute, or something similar, would make it convenient to delegate all events from a component or html tag,

// All events on a are delegated through the component.
<a on:>My Link</a>

[ekhaled]

on:* maybe?

[Conduitry]

Anything that involves listening to all events on a DOM element isn't practical. There was a conversation in Discord between @mindrones and me about this on December 6, 2018, that you can read for more information. Some relevant quotes:

The best I thing I can find with a quick google for binding to all DOM events on an element is to iterate through all the methods on the element whose names begin with on which isn't too reliable

I don't see how to implement this feature for DOM events without an awful unreliable hack that I don't think Svelte wants to be responsible for

People can of course do this in their own code if they want, but I really don't think it should be an official feature

[mrkishi]

Yesterday on Discord, Tor brought up the idea of exposing an "event target" for a component. If you tried to add a listener on a component, it'd be delegated to that target instead.

I think this would be a fine syntax for that: instead of preemptively adding listeners to everything, each components' $on could either be the default or just a proxy to a child component's $on or child dom node's addEventListener. This could work, no?

[Conduitry]

Oh that's interesting. So we wouldn't be forwarding all of them, just the ones that consumers of the component are trying to listen to. I don't see any technical DOM limitations getting in the way of that. There do still seem to be some questions though: Which events would attaching a handler attempt to proxy? all of them? Can we do this in a way that doesn't impact people not using it? Reopening to discuss this.

[ekhaled]

just to add my 2 cents here...
In svelte 2 we could monkey-patch Component.prototype.fire to emulate this.
This allowed us to have a near-enough implementation of Higher Order Components.

Since the internals have changed in svelte 3... the only way we can have some semblance of HoCs.. is if we have compiler support.

[Conduitry]

Monkey patching Component.prototype.fire only helped with listening to all events on a component, not on a DOM element.

There are a few different things going on here:

• <element on:*> - this is the event target thing that @mrkishi mentioned. There are some details to iron out but it seems possible.
• <element on:*={handler}> - this is not possible to implement in a sane way
• <Component on:*> - probably possible, using a similar event target thing, but for component events
• <Component on:*={handler}> - probably also possible. The interface would actually be simpler than it was in v2, since we are now using CustomEvents which have a type field, and we don't need to pass the type and the event payload separately

[Conduitry]

I just realized that <Component on:*={handler}> where the component contains <element on:*> would have to have caveats about not being able to report proxied DOM events from that element. So I'm withdrawing my support for the handler syntax. I think just allowing the forwarding on:* on DOM elements and components makes sense.

[hperrin]

If anyone needs this functionality, I've made a primitive approach to forward all standard UI events, plus any others you specify:

https://github.com/hperrin/svelte-material-ui/blob/273ded17c978ece3dd87f32a58dd9839e5c61325/components/forwardEvents.js

You can see how it's used in the Button component:

https://github.com/hperrin/svelte-material-ui/blob/273ded17c978ece3dd87f32a58dd9839e5c61325/components/button/index.svelte#L3

This is effectively the same as using a bunch of on:event directives with no handlers, but it will create less code. However, it uses internal Svelte features that may change without warning in the future.

Edit:
Updated on 2023-03-05 here: #2837 (comment)

[deviprsd]

Here is how I think it should get implemented,

• The compiler will be able to scope on:* with it's component when it has been implemented, so it shouldn't be a big change.
• EventHandler gets compiled to run-time listen(...). This function can be changed to a subscribe/unsubscribe pattern, that maps the node and it's modifiers in some kind of data structures (if possible use fragment scope ids as keys).
• Every time there is a new event it gets bound to the document with some new run time function as handler that will delegate the event to the appropriate callbacks and it's modifiers are then applied.
• The listen(...) will return an unsubscribe that will be called when the fragment is destroyed, it should be fine to remove an event if there are no handlers left for that event.
• I think this presents better opportunities to implement a bubbling mechanism as well
• Reduces number of attaching/de-attaching listeners, seems more likely to improve performance

Few more advantages, https://gomakethings.com/why-event-delegation-is-a-better-way-to-listen-for-events-in-vanilla-js/