Re: [whatwg/dom] Removing event listeners through an identifier (#208)

@mkay581 same story, I have used libraries as well. Example

```js
// one handler, many events at once grouped
$('body').add({
  click: function (e) {
    console.log(e.type);
    // release an event from the hnadler, no leaks, no callbacks
    this.releaseEvent(e);
  }
});

// one or more events
$(document.documentElement).addHandler({
  click: function (e) {
    console.log(e.type);
  },
  dropHandler: function (e) {
    Handler.remove(e.currentTarget, this);
  }
});

// with extra info
$(document.documentElement).add({
  clickCapture: true,
  click: function (e) {
    console.log(e.type);
  }
});
```

You've got the idea. The `handleEvent` pattern is the solution to most problems developers have, they just don't know/use this pattern because jQuery core at John time probably didn't use or know about such pattern so it didn't gain much attention.

All I am saying is that not all web developers learned from jQuery so using it as reference from a standard point of view sounds a bit weird, specially when maybe what developers need to know is a bit more about `handleEvent`, which I've no idea why it's not advocated: it's the best solution in terms of sharing resources, less RAM, etc ... and it's easy to trace it compared to held bound methods or arrow function, specially when the goal is to preserve a context but here all it's solved is a group of events while I'd rather improve that third option with a `context` to use during the execution.

At that point you'll have all patterns you want and the problem of the bound callback or arrow function solved too.

As it is now it looks like this proposal will fix partially the problem and developers will write even more arrow and bound methods in the wild :man_shrugging: 

Just my 2 cents.

Best Regards

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/208#issuecomment-311361956