-
Notifications
You must be signed in to change notification settings - Fork 382
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
components v1 native implementation - inner components problem #615
Comments
Ispend so many time((. |
@tnikolai2 could you provide your test cases via jsbin.com (or your favorite service) so people can reproduce the case and understand easily? If it is specific to Chrome, you can file a bug at http://crbug.com . Usually people get confused when looking at For constructor, you can refer to this document: |
now document.write('aa TAG2 bb'); also incorrect |
I don't understand what you are talking about "incorrect". Please provide live test cases about "variants" you are talking about (using http://jsbin.com or something) that we can verify, and what is your expectation and what is not your expectation. |
That's the intended behavior. You can't assume a particular tree at construction time or insertion time as custom elements can also be created via |
but with innerHTML connectedCallback can access and modify children content. With document.write it also worked before. |
And it still can. But you have to understand that the children might not yet been inserted. |
I'm just seeing error message on Chrome with the jsbin demo,
So I'm not completely sure the problem you are encountering, but as I understand @annevk's comment, the behavior you are seeing is working as expected. When HTML parser parses a custom element, it connects the parsed custom element after calling its constructor, but before connecting all the children which are not yet parsed. On the other hand, if all the custom elements are parsed but not upgraded (e.g. you put the custom elements in HTML before script that defines the custom element runs), when they are upgraded they can see their children, as they are already parsed and all connected ( Closing this as working as expected. |
http://jsbin.com/fopozupofa/1/edit?html,console,output <script> div.innerHTML='aa TAG2 bb'; //xx document.write('Four: aa TAG2 bb'); //xxaa TAG2 bb </script> Variant 4 runs after 3, where all was upgraded, but it same as 1 and 2 - very strange |
I fix error, but problem left http://jsbin.com/fopozupofa/1/edit?html,output
…Вторник, 11 июля 2017, 6:14 +03:00 от Takayoshi Kochi ***@***.***>:
I'm just seeing error message on Chrome with the jsbin demo,
"error"
"TypeError: Illegal constructor
at <anonymous>:9:11
at https://static.jsbin.com/js/prod/runner-4.0.4.min.js:1:13850
at https://static.jsbin.com/js/prod/runner-4.0.4.min.js:1:10792"
...
So I'm not completely sure the problem you are encountering, but as I understand @annevk 's comment, the behavior you are seeing is working as expected.
When HTML parser parses a custom element, it connects the parsed custom element after calling its constructor, but before connecting all the children which are not yet parsed. On the other hand, if all the custom elements are parsed but not upgraded (e.g. you put the custom elements in HTML before script that defines the custom element runs), when they are upgraded they can see their children, as they are already parsed and all connected (.innerHTML also parses, inserts, and then upgrades them, so you can see children).
Closing this as working as expected.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub , or mute the thread .
|
Thanks for fixing the jsbin demo. I can see your problem now. So when HTML parser sees the
which results in showing For 1 In this case, Both cases are expected with the current specification. So in general, you are allowed to touch I tested with Safari (10.1.1 and TP34), and all 4 cases show @rniwa @dominiccooney @domenic looks like the timings of running |
I do table tag, that contains column definition in nested tags. With fragment parser- it good, but with HTML parser need use mutation observers or some other hard logic to avoid this problems. If custom component has nested components, it always must be parsed as fragment, otherwise what can do inside connectedCallback? If cannot see/modify nested elements - nested tags is almost useless |
You might need a different callback, (imagine something like " I have heard from other authors that a callback at this time would be useful; the use case is to delay initialization work that would be invalidated by markup children (like OBJECT/PARAM.) You still have to use MutationObservers to track DOM changes; this use case is for performance optimization. Depending on the timing of the callback it might also simplify when to start listening to mutation events (because today you get no clear signal whether your constructor was invoked for upgrade, and you should process existing children, or not. This callback could be an opportunity to put that code in one place.) |
That's the callback you'd need to implement the |
Better in customElements.define add attribute "isContainer". This component must be connected only after parsing child content. It makes no sense to connect it before the childrens parsed, component anyway will change its content. Also i have problem with removing children components for my componens like m-form,m-table,m-modaldiv. When i rewrite innerHTML in connectedCallback, for old removed children components anyway invoked connectedCallback. And in connectedCallback must do check firstly: It not simple to get rid of removed components. For container component rewriting innerHTML must fully kill existing children components. For container component before connectedCallback children must be only parsed. After container connectedCallback finished, need connect actual children content. |
@TakayoshiKochi FWIW, yes, that does seem like a problem. As far as I know Safari would be wrong there, but @domenic should know for sure. I thought we had tests for things like this? |
F2F resolution: closing in favor of #809 |
for example :
HTML:
'<tag1>aa<tag2></tag2>bb</tag1>'
in tag1.connectedCallback (at chrome native v1 implementation ) this.innerHTML contain only "aa"
and this.childNodes contain one text node "aa".
'<tag2></tag2>bb</tag1>'
appended only after component tag1 renderered.If i do: tag1.connectedCallback(){ this.innerHTML='xx';}
result is
'<tag1>xx<tag2></tag2>bb</tag1>'
So at chrome native v1 implementation at connectedCallback
if component contain nested components, innerHTML and childNodes contain only data before first inner component occurence.
at v0 and non-native v1 implementation innerHTML all time contain correct value
'aa<tag2></tag2>bb'
What can do with this problem?
Sample page:
The text was updated successfully, but these errors were encountered: