RE: [components] Isolated Imports and Foreign Custom Elements

If you take a look at [1], we extend the custom elements registration mechanism so that the constructor is still available in the hosting global, yet the implementation is defined in the isolated environment.

An approach to solving this might address another concern I have...

I've been thinking about the way that the APIs are created with my proposal and the design wherein you have an explicit API to create the API signature on the prototype (and instances) leaves a lot of room for potential issues. For example:
* Nothing requires the isolated component to create any APIs initially (leaving the custom element without any API until some random later time of the isolated component's choosing).
* There is no way to know when the isolated component's APIs creation is "done"
* The isolated component can remove APIs at any time; this is not a pattern that user agents ever make use of and there's no use case for it--doesn't seem appropriate to give this power to the isolated component

To address these problems, if you change the model to work more like what Maciej proposed where you can have N number of custom elements defined by one global, then in the creation of a particular custom element (specifically it's prototype) you can specify what APIs should be defined on it in one shot (creation time) and don't provide any other way to do it. This naturally satisfies my above concerns. So, a rough sketch might be something like:

   void exportElement(DOMString customElementName, PropDescDictionary definitions);

usage example:

```js
document.exportElement("element-name", {
    api1: { enumerable: true, value: function() { return "hello, from the isolated component"; }},
    api2: { /* etc... */ }
});
// returns void (or throws is "element-name" is already defined/exported?)
```

Once you divorce the isolated component in this way, you rightly point out the problem of how to get the custom element's constructor function exported outside of the isolated environment. One possible approach to solve this allows the host to ask for the custom element constructor function explicitly. Rough idea:

    Function importConstructor("element-name");

usage example:

```js
window.MyElementName = document.importConstructor("element-name");
// now new MyElementName(); returns an instance of "element-name" element
```

You can imagine this might be useful for any custom element (either those exported as shown above, or those defined using registerElement -- the non-isolated custom elements).

Just some food for thought.

[1] https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal


-----Original Message-----
From: Anne van Kesteren [mailto:annevk@annevk.nl] 
Sent: Friday, May 1, 2015 9:48 AM
To: Maciej Stachowiak
Cc: WebApps WG
Subject: Re: [components] Isolated Imports and Foreign Custom Elements

On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I wrote up a proposal (with input and advice from Ryosuke Niwa) on a 
> possible way to extend Web Components to support fully isolated components:
>
> https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal

>
> I welcome comments on whether this approach makes sense.

I don't get the bit where you create a node in one global, but run its constructor in another. That seems rather Frankenstein-esque. Would love to see more details overall, as the direction this is going in certainly seems like the kind of thing we want. Allowing a dozen Facebook Like buttons to appear on a page using only one additional global.


--
https://annevankesteren.nl/

Received on Friday, 1 May 2015 17:47:24 UTC