Subject=Re: Re: Better way to maintain this reference on event listener functions

# Mark Kennedy (9 years ago)

[delete please] mistake

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()`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/b0d878c8/attachment.html>

# Andrea Giammarchi (9 years ago)

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 ....

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

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:28 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()`.
>
>
> _______________________________________________
> 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/65b21f5d/attachment.html>

# Domenic Denicola (9 years ago)

To give some clarity to "whose concern is it", the idea of it being an ES concern is that this is a concern for all APIs that accept a callback. addEventListener is a simple example.

I think ES has already given an answer to this question: Function.prototype.bind. I'm not sure what the OP was hoping to accomplish that could not already be accomplished with bind. Any possible mechanism (e.g. syntactic sugar for a (thisArg, function) pair) would essentially duplicate what bind does under the hood.

To give some clarity to "whose concern is it", the idea of it being an ES concern is that this is a concern for all APIs that accept a callback. addEventListener is a simple example.

I think ES has already given an answer to this question: `Function.prototype.bind`. I'm not sure what the OP was hoping to accomplish that could not already be accomplished with bind. Any possible mechanism (e.g. syntactic sugar for a (thisArg, function) pair) would essentially duplicate what bind does under the hood.