Re: Custom element design with ES6 classes and Element constructors

On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov <dslomov@chromium.org> wrote:
>
>
> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz <wycats@gmail.com> wrote:
>>
>> On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola <d@domenic.me> wrote:
>>
>> Isn't this at least a little future-hostile to things like `new
>> MyElement(attrs)`? Is there a way we could get back to that in the future,
>> in your mind?
>
>
> If this is what is desired, HTMLElement can pass all its arguments to
> createdCallback, i.e. call createdCallback(...args) in its constructor.
>
> Since default constructors pass all their arguments upstream,
>    new MyElement(attrs)
> will pass attrs as arguments to HTMLElement constructor. HTMLElement
> constructor needs no arguments itself, so it will pass all of those to
> MyElement's createdCallback.

Another option is to provide a species function, which would be what
the UA calls.

One of the problems with just forwarding the args is that the default
arguments to HTMLElement constructor already has a bunch of
parameters, as in the strawman at
https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L88

>> Can you say more about why same-identity upgrading is critical to the
>> design (as opposed to dom-mutation upgrading)? I asked up-thread but didn't
>> get any takers.

I think these points have been pointed out before but I'll list them again:

 * Identity - Elements used as keys in maps etc
 * Hidden state - cloneNode copies some internal state but generally
not enough (scroll position, selection, event listeners etc)
 * Mutation record spam
 * JS properties that are not reflected are lost

>>> On a final note, we could further bikeshed the name of createdCallback(),
>>> e.g. to either use a symbol or to be named something short and appealing
>>> like initialize() or create(), if that would make it even more appealing :)
>>
>>
>> I think symbols are actually pretty important here.
>>
>> To elaborate, I envision a future where Ember tries to move its Component
>> API to be "just a DOM subclass". So when you inherit from Ember's
>> `Component`, you're actually inheriting from a DOM `HTMLElement` too.
>>
>> document.register('my-element', class extends EmberComponent {
>>
>> });
>>
>>
>> But Ember already has a whole suite of methods and properties on
>> `Ember.Component`, some of which may accidentally conflict with these
>> callbacks (now and in the future).
>>
>> More generally, once people start writing libraries of HTMLElement
>> subclasses, our ability to add new callback names for all elements is going
>> to become pretty dicey, and we'll probably be forced into symbols anyway. We
>> may as well avoid a future inconsistency and just namespace DOM-supplied
>> callbacks separately from user-supplied properties and methods.

I'm sympathetic to this but I think it is fine that DOM continues to
define new string based property names. Anytime we add a new property
to an existing class we run into this issue and I don't think we want
to give up on the superior usability of string based property names.


-- 
erik

Received on Thursday, 15 January 2015 16:03:06 UTC