Re: [webcomponents] Auto-creating shadow DOM for custom elements

You cannot pass the shadow root to the constructor, because each class in
the chain can have it's own shadow root. This is the core of the problem.



On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 9, 2013, at 11:13 AM, Scott Miles <sjmiles@google.com> wrote:
>
> Domenic Denicola a few messages back gave a highly cogent explanation of
> the exact line of thinking arrived at last time we went through all this
> material.
>
> I'm not wont to try to summarize it here, since he said it already better
> there. Perhaps the short version is: nobody knows what the 'standard use
> case' is yet.
>
> In previous adjudications, the straw that broke that camel's back was with
> respect to handling auto-generation with inheritance. Shadow-roots may need
> to be generated for each entry in the inheritance chain. Having the system
> perform this task takes it out of the control of the user's code, which
> otherwise has ability to modulate calls to super-class methods and manage
> this process.
>
> class XFoo {
>  constructor_or_createdCallback: function() {
> // my shadowRoot was auto-generated
>    this.doUsefulStuffLikeDatabinding(this.shadowRoot);
>  }
> }
>
> class XBar extends XFoo {
>  constructor_or_createdCallback: function() {
>    super(); // uh-oh, super call operates on wrong shadowRoot
>  }
> }
>
>
> If the shadow root is optionally automatically generated, it should
> probably be passed to the createdCallback (or constructor) rather than made
> a property named "shadowRoot". That makes it possible to pass a different
> shadow root to the base class than to the derived class, thus solving the
> problem.
>
> Using an object property named "shadowRoot" would be a bad idea in any
> case since it automatically breaks encapsulation. There needs to be a
> private way to store the shadow root, either using ES6 symbols, or some new
> mechanism specific to custom elements. As it is, there's no way for ES5
> custom elements to have private storage, which seems like a problem. They
> can't even use the closure approach, because the constructor is not called
> and the methods are expected to be on the prototype. (I guess you could
> create per-instance copies of the methods closing over the private data in
> the created callback, but that would preclude prototype monkeypatching of
> the sort built-in HTML elements allow.)
>
> Regards,
> Maciej
>
>
>