Better way to maintain this reference on event listener functions

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon May 9 13:52:24 UTC 2016


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.giammarchi at 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 <mkay581 at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/000dec64/attachment.html>


More information about the es-discuss mailing list