From: Domenic Denicola [mailto:d...@domenic.me]
>
>From: Travis Leithead [mailto:travis.leith...@microsoft.com]
>
>> Something magical happens here. The use of super() is supposed to call the
>> constructor of the HTMLElement class—but that’s not a normal JS class. It
>> doesn’t have a defined constructor() method [yet?].
>
>Yep. We'd need to define one; it's absolutely required. ES2015 classes that
>don't call super() in their constructor simply aren't allowed, which means
>inheriting from a constructor that throws (like HTMLElement currently does) is
>impossible.
>
>https://github.com/domenic/element-constructors is a start at this.
Hmm. This does help. A lot. I wasn't aware that ES2015 classes added all these
restrictions on top of the syntactic sugar over the classing function
technique. Now I have some study to do to catch up. One question though before
I do that: if super() is absolutely required for a constructor in a class that
extends something, is there a requirement about when in the constructor method
it be invoked? Must it always be the first call? Can it be later on, say at the
end of the function?
>I take it when you said in [1]:
>
> I've discussed this issue with some of Edge's key parser developers. From a
> technical ground, we do not have a problem with stopping the parser to
> callout to author code in order to run a constructor, either during parsing
> or cloning. For example, in parsing, I would expect that the callout happens
> after initial instance creation, but before the target node is attached to
> the DOM tree by the parser.
>
>you were not aware of this? Maybe now you better understand my follow-up
>question in [2],
Yep. :-|
>> window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
>
>Why is XFoo different from XFooStartup? If I define a method in XFooStartup,
>does it exist in XFoo?
This won't work as I described it, given what you've told me, but my assumption
was essentially, that XFooStartup would act as if it didn't really depend on
HTMLElement for construction. So, it's constructor wouldn't be linked to the
actual custom element creation. Therefore XFoo (the platform-provided
constructor function is the thing that is actually used to trigger
construction, which would then result in the XFooStartup constructor running.
Basically, like this (reverting to non-class syntax):
function XFooStartup(val1, val2) {
this.prop = val1;
this.prop2 = val2;
}
window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
all I was trying to express different from the current design is:
1) replacing the createdCallback with the function constructor (and passing the
new element instance as 'this' when calling it)
2) passing through params from the XFoo platform-native constructor to the
XFooStartup function
3) calling XFooStartup synchronously
