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

Using this.$.[id] syntax yields different results in Canary than when using Polyfill #308

Closed
labriola opened this issue Oct 8, 2013 · 10 comments

Comments

@labriola
Copy link

labriola commented Oct 8, 2013

Given a node like this inside of the main template of a polymer-element:

<ul id="list"></ul>

var list = this.$.list;

In Canary, this expression yields:

<ul id="list">..</ul>

In Chrome, this expression yields:

b {impl: ul#list, parentNode_: undefined, firstChild_: undefined, lastChild_: undefined, nextSibling_: undefined…}

Wherein the variable named list when using Canary is equal to the list.impl when using Chrome.

@dfreedm
Copy link
Member

dfreedm commented Oct 8, 2013

This is an artifact of the ShadowDOM Polyfill, which runs in everything but Canary. In essence, the ShadowDOM Polyfill wraps over elements to fix up all the element reference pointers and querying apis to replicate the local dom tree effects of native ShadowDOM.

The Wrapper object you see has getters set up to directly access this.impl, the wrapped object, and overrides in only the necessary places.

@dfreedm
Copy link
Member

dfreedm commented Oct 8, 2013

In particular, those underscore postfixed elements on the wrapper object are cached copies of their regularly named counterparts.

@labriola
Copy link
Author

labriola commented Oct 8, 2013

When I dig further, it seems to me as though its an artifact of the querySelectorAll() polyfill. However, that aside, wouldn't this mean that a developer cannot use this.$.[id] as indicated in the documentation if they want their code to work with? As this will not yield the correct object

@labriola
Copy link
Author

labriola commented Oct 8, 2013

The reason I mention the querySelectorAll() is that even elements of the document, which are not inside of a shadow dom, return with that same signature I mention above. So placing a button in the body:

<button id="foo">Yo</button>

Is represented as the following object returned from document.querySelectorAll():

i {impl: button#foo, parentNode_: undefined, firstChild_: undefined, lastChild_: undefined, nextSibling_: undefined…}

@dfreedm
Copy link
Member

dfreedm commented Oct 8, 2013

There is no querySelectorAll polyfill, only ShadowDOM polyfill. It wrap all use of querySelector and querySelectorAll to maintain the scoping rules of ShadowDOM.

The wrapper object returned from these calls behaves identically to the actual DOM element. It will even pass instanceof checks.

Therefore, this.$.[id] should work as described. Can you give an example of having a problem with this?

@arv
Copy link
Contributor

arv commented Oct 8, 2013

@labriola it is unclear what problem you are having. It is true that the dev tools do not print things the same way but that should not cause any issue.

The goal of the shadow dom polyfill is to return a wrapper of the underlying dom object at all times so that we can keep object identity.

@labriola
Copy link
Author

labriola commented Oct 8, 2013

Here is a more concrete example. I get the goal, honest :) It's more that there is something else going on. I just initially followed a red herring.

<ul id="foo">
  <li>Test
</ul>

yield the following results:

document.querySelectorAll("[id]")[3]

//b {impl: ul#foo, parentNode_: undefined, firstChild_: undefined, lastChild_: undefined, nextSibling_: undefined…}

document.querySelectorAll("[id]")[3].hasChildNodes(); //false

document.querySelectorAll("[id]")[3].impl.hasChildNodes(); //true

@arv
Copy link
Contributor

arv commented Oct 8, 2013

@labriola There are cases when those two should be different and it is impossible to tell if you are running into one of those cases without more context. Can you create a test case on jsbin and provide a link?

@labriola
Copy link
Author

labriola commented Oct 8, 2013

Sure. Now that I get a bit more what's going on we could close this issue and open a new one with a more apt description. I think I see the actual issue so I will create one for it and add a link there

@labriola labriola closed this as completed Oct 8, 2013
@arv
Copy link
Contributor

arv commented Oct 8, 2013

Thanks

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