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

mark

Sent while riding a hoverboard...
heyimmark.com :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/8cd74f39/attachment-0001.html>

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 remove the listener appropriately 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 a 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)
    }
}

```

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 remove the listener appropriately 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)
    }
}

```

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)
    }
}

```

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)
    }
}

```

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)
}
}

```