RE: alternate view on constructors for custom elements

From: Domenic Denicola [mailto:d@domenic.me] 
>
>From: Travis Leithead [mailto:travis.leithead@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

Received on Friday, 17 July 2015 20:15:05 UTC