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

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 Wednesday, 7 November 2012 18:36:53 UTC