Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable picked by constructor attribute is set after upgrade events. #398

Closed
jyasskin opened this issue Jan 18, 2014 · 6 comments
Closed
Assignees

Comments

@jyasskin
Copy link

http://jsbin.com/uSEVOkEN/2/edit?html,console,output shows that the constructor attribute on the <polymer-element> element creates the variable on window after the upgrade events happen, which makes it difficult to reference any constructors inside an upgrade event. Polymer 0.1.1 set the window attribute before upgrading anything, but 0.1.2 and 0.1.3 have the same, unexpected behavior.

@sorvell
Copy link
Contributor

sorvell commented Jan 23, 2014

An element's constructor is not available in its createdCallback. This is
by spec (
http://w3c.github.io/webcomponents/spec/custom/#extensions-to-document-interface-to-register).
Note that the call to registerElement returns the element constructor.
Elements are upgraded before registerElement returns.

On Sat, Jan 18, 2014 at 2:28 PM, Jeffrey Yasskin
[email protected]:

http://jsbin.com/uSEVOkEN/2/edit?html,console,output shows that the
constructor attribute on the element creates the
variable on window after the upgrade events happen, which makes it
difficult to reference any constructors inside an upgrade event. Polymer
0.1.1 set the window attribute before upgrading anything, but 0.1.2 and
0.1.3 have the same, unexpected behavior.


Reply to this email directly or view it on GitHubhttps://github.com//issues/398
.

@jyasskin
Copy link
Author

'k, thanks. @ebidel, I think it'd be worth calling this timing out in http://www.polymer-project.org/polymer.html#attributes. The timing is actually a little "worse" than I'd thought when filing the bug: even postponing the traversal with this.async() only lets the current constructor get assigned. Any custom elements imported later are still not usable with instanceof. I actually have to wait until the WebComponentsReady event to have all constructors available.

Waiting until after created makes it more difficult to let the same code run with and without the shadow dom polyfill, since the polyfill rearranges the child elements before ready() runs. But it looks like the upgrade order I'd understood (children->parents) was only ever within elements of the same type, and so I couldn't use the pre-polyfill tree anyway.

Thanks again for the explanation.

@jyasskin
Copy link
Author

I'd missed http://www.polymer-project.org/platform/shadow-dom.html#wrappers, but that means I'm seeing an element get the wrong result from instanceof. https://gist.github.com/jyasskin/8575145 has the code, but it shows different behavior between jsbin and a local server.

@sjmiles
Copy link
Contributor

sjmiles commented Jan 23, 2014

If you declare cxx-function before cxx-section, CxxFunctionElement is available before the cxx-section code runs.

See: http://jsbin.com/esUxoHet/1/edit

@jyasskin
Copy link
Author

I filed a separate bug #402 for the instanceof problem, since this one was originally about the timing of upgrade events (which just needs better documentation now), while #402 happens even after WebComponentsReady. Note that using jsbin as opposed to a direct server makes it work, and I've reversed the <polymer-element>s in the current version without effect.

@sjmiles
Copy link
Contributor

sjmiles commented Aug 18, 2014

I tried the test that I posted on jsbin on my direct server and the behavior was not different. From this perspective it seems to me this is working as designed.

If I missed something important, please re-open this ticket.

@sjmiles sjmiles closed this as completed Aug 18, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants