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:ann...@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 <m...@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/
