Re: [Custom Elements] They are globals.

2016-04-12 Thread /#!/JoePea
On Mon, Apr 11, 2016 at 4:44 PM, Ryosuke Niwa wrote: > You'd have to instead write it as "new SomeClass(this.shadowRoot)" and then > (1) needs to be modified as: `super(..arguments)` to pass the argument along > to the HTMLElement constructor. For sure, similar to the examples

Re: [Custom Elements] They are globals.

2016-04-11 Thread Ryosuke Niwa
> On Apr 11, 2016, at 2:29 PM, /#!/JoePea wrote: > > What if custom elements can be registered on a shadow-root basis, so > that the author of a Custom Element (one that isn't registered by > default) can register a bunch of elements that it's shadow root will > use, passing

Re: [Custom Elements] They are globals.

2016-04-11 Thread /#!/JoePea
I get what you mean about the behaviors defined from classes that exist in the scope, in React. The really great thing about React is the ability to compose a class by using multiple classes to return the render spec. One of React's strong-points at a high level is it offers encapsulation where

RE: [Custom Elements] They are globals.

2016-04-11 Thread Domenic Denicola
I think you are being misled by a superficial similarity with React's JSX. JSX's `` desugars to `React.createElement(Foo)`, which creates a `` element with some of its behavior derived from the `Foo` class, found in JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.

Re: [Custom Elements] They are globals.

2016-04-11 Thread Ryosuke Niwa
> On Apr 11, 2016, at 9:02 AM, /#!/JoePea wrote: > > Is it possible to take an approach more similar to React where Custom > Elements aren't registered in a global pool? What if two libraries we'd like > to use define elements of the same name, and we wish to import these