Proxying Native Objects: Use case

David Bruant bruant.d at gmail.com
Thu Jan 31 07:50:30 PST 2013


Le 31/01/2013 16:10, François REMY a écrit :
> Hi.
>
> I must admit I didn't follow the whole thread about native element proxyfication but when I left the consensus was that the native element should not be proxied (ie: it would not work like Object.create(...) do not work for them).
Just to clarify, both for Object.create and proxy, your "does not work" 
means "cannot be put in the DOM tree". The output object still behaves 
as expected from an ECMAScript point of view.
It remain possible to do wrappedNode1.appendChild(wrappedNode2) by 
unwrapping both wrappedNode under the hood.

> I've however a compelling use case that may make some of us rethink the situation.
>
>
> Let's say I want to implement a polyfill for MapEvent whose definition is as follows:
>
>      interface MapEvent : Event {
>          getter any item(DOMString name);
>      }
Out of curiosity, where does MapEvent come from? I can't remember having 
read about it on any spec and Google isn't helping.
As a side note, I hope this is not a new API, because such getters are 
particularly bad taste. I remember it generated some issues with 
HTMLCollection. Maybe something about making it inherit from Array and 
static analysis on websites.
I think such a getter notation exists in WebIDL to formalize scars from 
the past (like HTMLCollection) rather than to be used in new APIs

For this kind of API, I largely prefer the CustomEvent approach where 
the (unique!) "detail" field is by-spec expected to be a "go crazy" type 
of field. The "detail" attribute also doesn't collide with any existing 
field; in the MapEvent case, a getter could shadow an inherited property.

> In case of no-proxy-for-native-objects, I've no way to do it properly because implementing 'getter' requires me to use a Proxy but having a functional event will force me to use a natively-branded element (like document.createEvent("CustomEvent")) and changes its prototype chain to match my needs.
The conclusion I was personally at was that every single API will have 
to decide how it behaves with proxies. We've seen previously that 
proxies in appendChild were a no-go because browsers traverse the DOM 
tree for selector matching and putting proxies in the tree would reveal 
how selector matching is performed, thus ruining hope of making it parallel.
However, off top of my head, I don't see a main restriction to call 
.dispatch with a proxied event as argument. I'm not enough expert of 
this topic; people who are in how the APIs are used and implemented will 
better tell whether it's appropriate to accept a proxy.

I'll post to public-script-coord to talk about that.

David


More information about the es-discuss mailing list