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

Why does each class in the chain need a "shadow root"?

It seems to me that each class just needs a "root". If we model this
explicitly in the lifecycle with something like
'applyTemplateCallback(root)' then each inheritor is passed a dom element
(maybe it's in the shadow dom..maybe it isn't). The subclass then just adds
their visuals onto the root and then (optionally) calls to their base
class' implementation of applyTemplateCallback, passing whatever dom
element they want the super class to use as its root. The ultimate subclass
can be passed the actual shadow root automatically.

This allows subclasses to easily replace the super class' view or to
decorate it. If they only want to add behavior to an existing element
without changing the view, they just don't implement the callback at all.


On Fri, Dec 13, 2013 at 12:18 PM, Scott Miles <sjmiles@google.com> wrote:

> 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
>>
>>
>>
>


-- 
Rob Eisenberg,
President - Blue Spire
www.durandaljs.com