Re: Allowing ES6 Symbols as event names

On 7/22/14, 4:41 AM, David Bruant wrote:
> Why would someone use a symbol as first argument of .on, though?

Why would someone use it as first argument of addEventListener?

> The feature isn't documented. Right now, it's very clear that the first
> argument is a string http://api.jquery.com/on/

Um... people don't read documentation, typically.  They copy-paste-modify.

> But you stepped out of the documentation, you know the risks.

This literally made me laugh out loud, sorry.

> Right now, if you pass a boolean to .on, you get the same error while
> booleans are accepted as first argument of addEventListener (implicitly
> converted to string). I wonder what is so different about symbols.

That people will actually expect to listen for events with symbol types, 
unlike boolean types?

> Very much like browser extensions need to account for other new features
> (proxies, Maps, etc.).
> Why is this compat risk different/worse?

Because this risk affects extensions that deal with events, which we 
know exist.

Proxies/maps/etc don't affect extensions that don't use the features 
themselves and restrict themselves to DOM access, right?

>> and for any code that uses a library in this way and then has
>> something else dropped into the page that uses Symbol-named events.
> I don't understand this part. I read 3 parties :
> * your code
> * some library code your code uses and depends on
> * third-party code (potentially from a different domain)

It's more like:

* your code
* The code of the 10 other people who work at your organization and are 
adding stuff to that page.
* The library code your code uses and depends on.
* The library code the other 10 people's code uses and depends on.
* Third-party code
* The library code the third-party code depends on.

Of these, you really only control the first item and maybe the third.

> The third-party code uses Symbol-named events (with addEventListener
> since the library doesn't support them). But I don't understand how
> either it affects your code or depends on the library compatibility.
> The third party code is just leaving its life after symbols like it was
> doing before with you having very little control over its activity.

Maybe a concrete example would help.

Say you're this hypothetical conscientious documentation reader, even. 
You or a library you include have a little helper function that looks 
like this:

   function addListener(target, type, func) {
     target.addEventListener(type, function(e) {
       // Some processing here
       func.call(target, jQuery.event.fix(e));
     });
   }

which lets you add listeners, do some stuff, and then call functions 
that expect jQuery-style event objects. You looked at the docs, and saw 
nothing useful about fix(), but stack overflow is recommending it for 
the "convert a DOM event to a jQuery event" use case and all, so you use 
it.  You expose this API to the other 10 people who work with you and 
whatnot.

Now if someone calls addListener with a symbol type, it will all work 
fine until it comes time for the event to fire.  At which point it 
won't.  Agreed?

> I understand why browsers don't want to change APIs that would cause
> breakage of existing code that is served on the web. But I don't
> understand the reluctance to change an API that can only break new code.

Uh... If we posit that extensions are using catch-all event listeners 
then this would break existing extension code, right?  This is the part 
of the thread you were replying to here, so I don't understand your 
comment at all.

> but if that's an issue, then the language can never evolve, can it?

Look, some amount of (potential) breakage is presumably acceptable, 
because you're correct that otherwise you can never change anything.

It's always a question of how much breakage and whether the benefits you 
get are worth it.

> Yes. First reasonable thing to do would be to check whether the
> libraries you include do support this Symbol thing.

Libraries you include and the other 10 people include, right?

> Speaking of footguns, this sort of consideration is even worse when it
> comes to proxies. ES5 objects have plenty of things people expect from
> them (like "the value between two consecutive reads doesn't change")
> that are completely broken with proxies.

That invariant is even broken with ES5 getters.

> And passing proxies with various handlers to libraries will cause the
> same sort of breakage you're talking about. How is this different?

That involves passing a new kind of thing around, while my concern is 
with code that has an Event, passes around an Event, and discovers that 
suddenly there are some Events that a library can't operate on.  And the 
code that has the Event (and got it from some other code) can't really 
do anything about it...

-Boris

Received on Tuesday, 22 July 2014 12:36:48 UTC