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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dimitri Glazkov-3
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.

Reply | Threaded
Open this post in threaded view
|

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

Elliott Sprehn
I'm for 1) , having a constructor with side effects is confusing and inconsistent with the platform (and other languages).



On Wed, Nov 7, 2012 at 10:36 AM, Dimitri Glazkov <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

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

Maciej Stachowiak
In reply to this post by Dimitri Glazkov-3

Could you please provide equivalent code examples using both versions?

Cheers,
Maciej

On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]> 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.
>


Reply | Threaded
Open this post in threaded view
|

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

Dimitri Glazkov-3
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 <[hidden email]> wrote:

>
> Could you please provide equivalent code examples using both versions?
>
> Cheers,
> Maciej
>
> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]> 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.
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Elliott Sprehn-3
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> Could you please provide equivalent code examples using both versions?
>
> Cheers,
> Maciej
>
> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]> 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.
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Dimitri Glazkov-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >
>> > Could you please provide equivalent code examples using both versions?
>> >
>> > Cheers,
>> > Maciej
>> >
>> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]>
>> > 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.
>> >>
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

Elliott Sprehn-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >
>> > Could you please provide equivalent code examples using both versions?
>> >
>> > Cheers,
>> > Maciej
>> >
>> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]>
>> > 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.
>> >>
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

Erik Arvidsson-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> >> wrote:
>> >> >
>> >> > Could you please provide equivalent code examples using both
>> >> > versions?
>> >> >
>> >> > Cheers,
>> >> > Maciej
>> >> >
>> >> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]>
>> >> > 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

Reply | Threaded
Open this post in threaded view
|

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

Maciej Stachowiak

I think a factory function is better here for the reasons Dimitri stated. But I also agree that an addFoo function returning a new object seems strange. I think that createShadowRoot may be better than either option.

 - Maciej

On Nov 8, 2012, at 11:42 AM, Erik Arvidsson <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> Could you please provide equivalent code examples using both
>>>>>> versions?
>>>>>>
>>>>>> Cheers,
>>>>>> Maciej
>>>>>>
>>>>>> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]>
>>>>>> 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
>


Reply | Threaded
Open this post in threaded view
|

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

Elliott Sprehn-3
Sounds good to me. :)



On Fri, Nov 9, 2012 at 12:30 PM, Maciej Stachowiak <[hidden email]> wrote:

I think a factory function is better here for the reasons Dimitri stated. But I also agree that an addFoo function returning a new object seems strange. I think that createShadowRoot may be better than either option.

 - Maciej

On Nov 8, 2012, at 11:42 AM, Erik Arvidsson <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> Could you please provide equivalent code examples using both
>>>>>> versions?
>>>>>>
>>>>>> Cheers,
>>>>>> Maciej
>>>>>>
>>>>>> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <[hidden email]>
>>>>>> 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
>


Reply | Threaded
Open this post in threaded view
|

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

Dimitri Glazkov-3
I made the change to the editor's draft:
http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104

You can read the shiny new parts of the spec here:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element

Please let me know if I goofed up something, preferably by filing bugs :)

:DG<