Rename .on()?

[shama]

Originally I named it .on() for readability, such as el.on('click') or el.on('selected'). But I understand that is a commonly used name so maybe another would be better suited. Initiated by this: https://twitter.com/yoshuawuyts/status/597563041119608832

@yoshuawuyts Could you elaborate more on why .attachListener() would be a better name? Thanks!

[shama]

Pinging @yoshuawuyts @bendrucker @sethvincent for an opinion on whether or not .on() should be renamed. I am indifferent. Thanks for the input!

[shama]

Also @Flet, thanks!

[yoshuawuyts]

Oh shoot, forgot to come back on this.

I really like the .on() name to interact with, but as was pointed out to me by other developers it isn't compatible with how other elements in the browser work. Instead we might want to consider EventTarget.addEventListener. This way elements created with base-element can be used with any library that knows how to deal with regular DOM listeners.

There's a (broken) example of how this could be done here using synthetic-dom-events.

I think that would make a reasonable base, at a higher level .on() could be implemented by a system similar to dom-wrap or dom-on.

Does this make sense?

[bendrucker]

+1 to addEventListener. I think this could be like standard in that teams could publish ${name}-standard or a scoped npm package with the sugar methods they want.

[shama]

Ah interesting, that makes sense. I am also now +1 to addEventListener. Thanks!

[Flet]

This is sensible!

[yoshuawuyts]

wooh! 🎉