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

addShadowRoot seem wrong to me to. Usually add* methods takes an
argument of something that is supposed to be added to the context
object.

If we are going with a factory function I think that createShadowRoot
is the right name even though create methods have a lot of bad history
in the DOM APIs.

On Thu, Nov 8, 2012 at 1:01 PM, Elliott Sprehn <esprehn@google.com> wrote:
> True, though that's actually one character longer, probably two with normal
> formatting ;P
>
> new ShadowRoot(element,{
> element.addShadowRoot({
>
> I'm more concerned about the constructor with irreversible side effects of
> course.
>
> - E
>
>
> On Thu, Nov 8, 2012 at 9:57 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>>
>> That _is_ pretty nice, but we can add this as a second argument to the
>> constructor, as well:
>>
>> root = new ShadowRoot(element, {
>>   applyAuthorSheets: false,
>>   resetStyleInheritance: true
>> });
>>
>> At this point, the stakes are primarily in aesthetics... Which makes
>> the whole question so much more difficult to address objectively.
>>
>> :DG<
>>
>> On Thu, Nov 8, 2012 at 9:54 AM, Elliott Sprehn <esprehn@google.com> wrote:
>> > The real sugar I think is in the dictionary version of addShadowRoot:
>> >
>> > root = element.addShadowRoot({
>> >   applyAuthorSheets: false,
>> >   resetStyleInheritance: true
>> > })
>> >
>> >
>> > On Thu, Nov 8, 2012 at 9:49 AM, Dimitri Glazkov <dglazkov@google.com>
>> > wrote:
>> >>
>> >> 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.
>> >> >>
>> >> >
>> >
>> >
>
>



-- 
erik

Received on Thursday, 8 November 2012 19:43:23 UTC