Repository navigation
Using this.$.[id] syntax yields different results in Canary than when using Polyfill #308
Description
Activity
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.In particular, those underscore postfixed elements on the wrapper object are cached copies of their regularly named counterparts.
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
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…}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
instanceofchecks.Therefore,
this.$.[id]should work as described. Can you give an example of having a problem with this?@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.
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(); //trueSure. 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
Thanks
Given a node like this inside of the main template of a polymer-element:
In Canary, this expression yields:
In Chrome, this expression yields:
Wherein the variable named list when using Canary is equal to the list.impl when using Chrome.