🦋 Changeset detected

Latest commit: c5b92b1

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Playground

pnpm add https://pkg.pr.new/svelte@15856

Is this worth adding? It seems like it's a non-zero amount of complexity and overhead for a basically useless feature, but if there's a legitimate use for handleEvent objects I suppose it could make sense to match the DOM spec

Is this worth adding? It seems like it's a non-zero amount of complexity and overhead for a basically useless feature, but if there's a legitimate use for handleEvent objects I suppose it could make sense to match the DOM spec

I've been using this feature for a little while and have found it quite useful. Here's the article through which I found out about it, it's pretty interesting

Preview: https://svelte-dev-git-preview-svelte-15856-svelte.vercel.app/

Oh, somehow I've missed that this should be the object but not the element.

I'm also unclear on the real world benefit of this, can someone ELI5? I'm familiar with Andrea's article and I can't quite wrap my head around where it would be useful (though I do find myself wondering if we could take advantage of this approach internally instead of using delegation)

I'm also unclear on the real world benefit of this, can someone ELI5?

1. If you have an event handler(s) that you want to remove, it makes it a lot easier
2. A way to unify all event handlers that could be related to each other
3. Devs coming from vanilla JS might want to use it

though I do find myself wondering if we could take advantage of this approach internally instead of using delegation

I was actually thinking of making a PR that would do that, should I start working on it?

1. If you have an event handler(s) that you want to remove, it makes it a lot easier

How so? Is handler.handleEvent = null easier than handler = null?

2. A way to unify all event handlers that could be related to each other

Is it easier than doing this?

<script>
  const handlers = {
    onmouseenter() {
      console.log('enter');
    },
    onmouseleave() {
      console.log('leave');
    }
  };
</script>

<div {...handlers}></div>

What would it look like — this?

<script>
  const handler = {
    handleEvent(e) {
      this['on' + e.type]?.(e);
    },
    onmouseenter() {
      console.log('enter');
    },
    onmouseleave() {
      console.log('leave');
    }
  };
</script>

<div onmouseenter={handler} onmouseleave={handler}></div>

It doesn't seem like an improvement. Maybe I'm missing something but I'm struggling to come up with a scenario where it's helpful.

3. Devs coming from vanilla JS might want to use it

Aside from #8196 no-one has ever asked for it, so it feels like YAGNI to me.

I was actually thinking of making a PR that would do that, should I start working on it?

As long as you're at peace with the possibility that it wouldn't get merged 😅 it would have to have the same-or-better performance/memory characteristics, and not having any breaking changes in terms of timing etc. (It's possible that we'd actually be able to improve the timing situation, since handlers manually added with addEventListener would presumably no longer run in a distinct phase, but if that's considered a breaking change then this might have to wait until Svelte 6.)

I just looked at Solid's implementation and they also allow passing listener options on the object. Interesting idea. Though, they did it mostly to support adding listeners with the capture/passive/once options declaratively in the markup.

I did it just because the issue has the PRs welcome label 😄

It would be cool if this was supported

<script>
  const handler = {
    handleEvent(e) {
      this['on' + e.type]?.(e);
    },
    onmouseenter() {
      console.log('enter');
    },
    onmouseleave() {
      console.log('leave');
    }
  };
</script>

<div {...handler}></div>

By

element.addEventListener(event, handler);
// Repeat for all events...

But that way you add the event listeners but not the handleEvent. It should be rather

<div onmouseenter={handler} onmouseleave={handler}>

So, my opinion:

• Saving RAM - the era of "640kb RAM enough" was 4 decades ago, overhead of lambdas or bound function is barely noticeable. If RAM efficient code is needed - probably more light framework/library should be used or even vanilla JS. Also, Svelte already optimizes handlers by hoisting (though not in loops) - see the output.
• Single entry for all event handlers - it's convent for the developer, but not the end user as they have to add the handler to each event, somehow know the list of events and do not forget any of them. Using a dedicated object with listeners or attachment is more convenient for the end user, although it's more boilerplate, REPL:

<script>
  import { on } from "svelte/events"
  class MyItem {
    handlers = {
      onmouseenter: (ev) => this.onmouseenter(ev),
      onmouseleave: (ev) => this.onmouseleave(ev), 
    }
    addHandlers = (node) => {
      const offs = [
        on(node, "mouseenter", (ev) => this.onmouseenter(ev)),
        on(node, "mouseenter", (ev) => this.onmouseenter(ev)),
      ];
      return () => offs.forEach(off => off());
    }
    test = 42
    onmouseenter() {
      console.log('enter', this.test);
    }
    onmouseleave() {
      console.log('leave', this.test);
    }
  }
  let item = new MyItem();
</script>

<div {...item.handlers}>spreading</div>
<div {@attach item.addHandlers}>attachment</div>

• Always possible to remove a listener - Svelte does it for you, so it doesn't make sense here.
• this refers to the object, but not the element - probably the only real advantage.
• There is an interesting idea of passing listeners flags onclick={{ handleEvent() {...}, once: true, capture: true, passive: true }}, but:
  • once - can be easily worked around;
  • capture - supported as oneventnamecapture;
  • passive - nobody has asked for it yet.

Plus some disadvantages:

• It can cause some typing troubles because now the listeners can be an object.
• handleEvent is too little-known, unless we will advertise it in the docs and tutorial.

So, I tend to think that there is no real need for this feature. If a good use case appears, it can be re-opened.

But that way you add the event listeners but not the handleEvent. It should be rather

<div onmouseenter={handler} onmouseleave={handler}>

I meant that spread of object with handler could be handled by compiler compilation to the syntax after "by"...

This feature would be nice to have for a lib I'm working on...