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 in the GitHub iss
> 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 constructors that th
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 the
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.
Custom
> 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 via
> `import` and n
Hello,
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
via `import` and not modify the source code of our dependencies?
I don't r
