Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

Sure. Here's a simple example without getting into traversable shadow
trees (those are still being discussed in a different thread):

A1) Using constructable ShadowRoot:

var element = document.querySelector('div#foo');
// let's add a shadow root to element
var shadowRoot = new ShadowRoot(element);
// do work with it..
shadowRoot.applyAuthorSheets = false;
shadowRoot.appendChild(myDocumentFragment);

A2) Using addShadowRoot:

var element = document.querySelector('div#foo');
// let's add a shadow root to element
var shadowRoot = element.addShadowRoot();
// do work with it..
shadowRoot.applyAuthorSheets = false;
shadowRoot.appendChild(myDocumentFragment);

Now with traversable shadow trees:

B1) Using constructable ShadowRoot:

var element = document.querySelector('div#foo');
alert(element.shadowRoot); // null
var root = new ShadowRoot(element);
alert(root === element.shadowRoot); // true
var root2 = new ShadowRoot(element);
alert(root === element.shadowRoot); // false
alert(root2 === element.shadowRoot); // true

B2) Using addShadowRoot:

var element = document.querySelector('div#foo');
alert(element.shadowRoot); // null
var root = element.addShadowRoot();
alert(root === element.shadowRoot); // true
var root2 = element.addShadowRoot();
alert(root === element.shadowRoot); // false
alert(root2 === element.shadowRoot); // true

:DG<

On Thu, Nov 8, 2012 at 9:42 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Could you please provide equivalent code examples using both versions?
>
> Cheers,
> Maciej
>
> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>
>> Folks,
>>
>> Throughout the year-long (whoa!) history of the Shadow DOM spec,
>> various people commented on how odd the constructable ShadowRoot
>> pattern was:
>>
>> var root = new ShadowRoot(host); // both creates an instance *and*
>> makes an association between this instance and host.
>>
>> People (I cc'd most of them) noted various quirks, from the
>> side-effectey constructor to relatively uncommon style of the API.
>>
>> I once was of the strong opinion that having a nice, constructable
>> object has better ergonomics and would overcome the mentioned code
>> smells.
>>
>> But... As we're discussing traversable shadows and the possibility of
>> having Element.shadowRoot, the idea of changing to a factory pattern
>> now looks more appealing:
>>
>> var element = document.querySelector('div#foo');
>> alert(element.shadowRoot); // null
>> var root = element.addShadowRoot({ resetStyleInheritance: true });
>> alert(root === element.shadowRoot); // true
>> var root2 = element.addShadowRoot();
>> alert(root === element.shadowRoot); // false
>> alert(root2 === element.shadowRoot); // true
>>
>> You gotta admit this looks very consistent and natural relative to how
>> DOM APIs work today.
>>
>> We could still keep constructable object syntax as alternative method
>> or ditch it altogether and make calling constructor throw an
>> exception.
>>
>> What do you think, folks? In the spirit of last night's events, let's vote:
>>
>> 1) element.addShadowRoot rocks! Let's make it the One True Way!
>> 2) Keep ShadowRoot constructable! Factories stink!
>> 3) Let's have both!
>> 4) element.addShadowRoot, but ONLY if we have traversable shadow trees
>> 5) Kodos.
>>
>> :DG<
>>
>> P.S. I would like to retain the atomic quality of the operation:
>> instantiate+associate in one go. There's a whole forest of problems
>> awaits those who contemplate detached shadow roots.
>>
>

Received on Thursday, 8 November 2012 17:50:23 UTC