Re: Custom element design with ES6 classes and Element constructors

I'm also curios why DOM mutation is a problem.

I read arguments like using the nodes as a key in a Map but such code is
already broken as a node can also be replaced with some user code; so such
code should put into account the node replacement.

I also don't understand how the two-tier construction (<init> +
createCallback) fixes the issue about accessing siblings and parents. One
might still write problematic code in createdCallback as they will use it
as a replacement for constructor (e.g. accessing a sibling and calling an
instance method can easily fail as createdCallback not called on the
element yet).

I think, overall, trying to abstract the upgrade process is a big band-aid;
makes the upgrade more magical while not hiding away all implications.
Developers still need to be aware of the upgrade process and program
accordingly so I think it is better to be more explicit.

To me it sounds saner to create custom elements as HtmlUnknownElement at
the parsing stage (or HtmlUnitializedElement if it is necessary to
distinguish them) and then explicitly upgrade them bottom up by first
running the constructors and then replace the existing nodes with newly
created ones. After the construction the event listeners and properties can
be copied over to the new nodes. By this way, anyone who wants to traverse
tree can easily identify uninitialized nodes and act accordingly (e.g. add
a listener for an 'initialized' event).


On Tue, Jan 13, 2015 at 1:07 PM, Yehuda Katz <wycats@gmail.com> wrote:

> On Tue, Jan 13, 2015 at 9:50 AM, Domenic Denicola <d@domenic.me> wrote:
>
>> From: Boris Zbarsky [mailto:bzbarsky@mit.edu]
>>
>> > Just to be clear, this still didn't allow you to upgrade a <my-img> to
>> be a subclass of <img>, because that required a change in allocation, right?
>>
>> Agreed. That needs to be done with <img is="my-img">, IMO. (Assuming the
>> upgrading design doesn't get switched to DOM mutation, of course.)
>>
>
> Can someone help outline for me exactly why DOM mutation is a problem
> here? I can definitely see downsides, but DOM mutation is a fact of life
> when scripts are involved on today's web, and it sidesteps a lot of the
> problems that we encounter by trying to make in-place upgrading (upgrades
> without changing the reference at all) work sanely.
>
> I mean, qSA might not work the way someone might expect, but it also might
> not work if you go `$("my-button").button()` using jQuery. What expectation
> do we imagine someone has here that we think is missing if we use DOM
> mutation (rather than object-model mutation) for upgrades.
>
> -- Yehuda
>
>