Yes but what happens when you have multiple event targets using the same `type` of event? You're going to require a lot of extra conditionals in `onclick` method. Again this approach is cumbersome and, imo, not the most efficient.
These may not be the best solutions but here are a few options I've thought of: 1. When an arrow function is used as the second parameter to `addEventListener`, the language can evaluate and use its scoped context when the same function is used with a subsequent `removeEventListener call, so essentially the following code would work when calling destroy. ```js class MyClass { constructor () { someNode.addEventListener('click', (e) => this.onClick(e)) } onClick (e) { // do something here } destroy () { someNode.removeEventListener('click', (e) => this.onClick(e)) } } ``` 2. Another solution would be if we could maybe pass a method string as the second parameter and then an optional context as the fourth parameter to addEventListener and removeEventListener as follows: ```js class MyClass { constructor () { someNode.addEventListener('click', 'onClick', {}, this) } onClick (e) { // do something here } destroy () { someNode.removeEventListener('click', 'onClick', {}, this) } } ``` On Mon, May 9, 2016 at 9:52 AM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > uhm, I've used commas ... anyway, the sugar is desugaring to old methods, > this is working example: > > ```js > class SomeClass { > constructor(someNode) { > someNode.addEventListener('click', this); > } > onclick(e) { > alert(this.constructor.name); // SomeClass > } > handleEvent(e) { > this['on' + e.type](e); > } > } > > new SomeClass(document.documentElement); > ``` > > The difference with your example is that you will always be able to remove > the instance without needing to store upfront every bound listener. > > To know where the `addEventListener` was set you always have the > `e.currentTarget` so basically you have a weakmap between a node and an > object where you can always retrieve the initial node that used the object > through the event, keeping the node clean from "expando" links. > > More sugar than this, I'm not sure what would be. > > You could also have a simple naming convention where every method that > starts with `on` will be set as listener using the current instance, and do > the same, if necessary, on teardown/destroy. > > What kind of sugar would you use otherwise? > > The only proposal discussed so far is `el.addEventListener('click', :: > this.onClick)`, unfortunately that doesn't solve anything because AFAIK > they don't see any advantage in having `::this.onClick === ::this.onClick` > which is what I've raised already as "that's what developers would expect" > but apparently it's too costy or complicated or ... dunno. > > ¯\_(ツ)_/¯ > > Best Regards > > > > > > > > > > > On Mon, May 9, 2016 at 2:41 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> Raising a concern about `addEventListener` and its context probably made >> me think it was rather a WHATWG concern. >> >> Anyway, I don't know why you had to point out the `class` keyword ... I >> mean .... >> >> ```js >> class SomeClass { >> constructor(someNode) { >> someNode.addEventListener('click', this); >> }, >> onclick(e) { >> alert(this.constructor.name); // SomeClass >> }, >> handleEvent(e) { >> this['on' + e.type](e); >> } >> } >> ``` >> >> There you go >> >> Best Regards >> >> >> On Mon, May 9, 2016 at 2:38 PM, Mark Kennedy <mkay...@gmail.com> wrote: >> >>> Wow that's so ironic because [I posted this same idea]( >>> https://github.com/whatwg/dom/issues/245#issuecomment-217816301) >>> (literally >>> copied and pasted) in WHATWG's "DOM land" and they told me this was an >>> es-discuss issue. So which is it? >>> Oh and thanks for the code sample but it uses the old prototypical method >>> of replicating a class by creating a function which is now not the most >>> efficient way (there's the `class` keyword). And I don't see how what >>> you're doing isn't any different from a roundabout way of what I did. I >>> already know about the `handleEvent()` stuff, I like that it's available >>> and its polyfills. They are great, but my original question is to >>> implement >>> sugar so that you don't have to use polyfills or the `handleEvent()`. >>> -- >>> >>> mark >>> >>> Sent while riding a hoverboard... >>> heyimmark.com :) >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > -- mark Sent while riding a hoverboard... heyimmark.com :)
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss