Webcomponents: appreciate your feedback for custom element diagram

[AndyOGo]

Hy,

I just released an adapted version of the interactive react lifecycle methods diagram for custom elements:
https://andyogo.github.io/custom-element-reactions-diagram/

If you have time, I would appreciate your feedback very much.

Personally I'm still concerned of how to express details of custom element reactions, like it's connectedCallback queue glitch documented in the spec itself in the example below:

An element's connectedCallback can be queued before the element is disconnected, but as the callback queue is still processed, it results in a connectedCallback for an element that is no longer connected:
https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance

[AndyOGo]

@dglazkov
@hayatoito
@domenic
If you have any free time available I would appreciate your feedback a lot!

[daKmoR]

<div is="built-in"> you can't really find in the wild as it's mostly discouraged for the fact that safari is not going to implement it => so maybe just remove it?

Rest seems good to me although I'm not sure what the --> x at attributeChangedCallback, connectedCallback, adoptedCallback and custom properties means.

for custom properties I'm also not sure what does it mean in general in this context?

[AndyOGo]

@daKmoR
Thanks a lot for your input.

you can't really find in the wild as it's mostly discouraged for the fact that safari is not going to implement it => so maybe just remove it?

Indeed that's true, unfortunately Safari refuses to implement it. Though extended built-in elements are living standard and the majority supports it. Hence this diagram should reflect the standard, though an * asterisk with mentions below would make sense.

I'm not sure what the --> x at attributeChangedCallback, connectedCallback, adoptedCallback and custom properties means.

So the spec has still glitches, the behavior of these callbacks are not 100% deterministic.
The --> x shall show that there maybe glitch-checks needed.
For more info see this test page please:
https://wc-connected-test.glitch.me/

Also the spec itself notes about connectedCallback glitches like:

An element's connectedCallback can be queued before the element is disconnected, but as the callback queue is still processed, it results in a connectedCallback for an element that is no longer connected:
https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance

for custom properties I'm also not sure what does it mean in general in this context?

Okay, so every custom observed HTML attribute should have a corresponding DOM property.
More info: https://developers.google.com/web/fundamentals/web-components/best-practices#attributes-properties

[AndyOGo]

@daKmoR
@rniwa
I just released some updates:
https://andyogo.github.io/custom-element-reactions-diagram/

Feedback very welcome

[web-padawan]

Consider removing some of the locales as they still mention React (at least, Russian and Ukrainian).

Also, the "version toggle" does not make much sense to me. Custom Elements "v1" are the only stable version at the moment, what was previously called "v0" is about to be removed from Chrome.

[AndyOGo]

@web-padawan
Thanks for your feedback.
Agree, language issues are tracked https://github.com/AndyOGo/custom-element-reactions-diagram/issues/2 and I would need the help of native speakers within the community

[daKmoR]

hey really cool update :) I think it has all the core information now :)

small nitpick can we change

Webkit rejects extended built-in elements.

to something like this

Webkit rejects extended built-in elements, therefore, elements using this will not work on IPhone or Safari

(We should make it really apparent what that means to the end user)

[AndyOGo]

@daKmoR Thanks, is updated:)

[daKmoR]

The --> x shall show that there maybe glitch-checks needed.

can we add a "legend" or so for this... I already forgot it and was again a little confused about its meaning 🙈

[AndyOGo]

@daKmoR here you go, thanks for your feedback.

[justinfagnani]

@AndyOGo I just took a look, and it seems like you're trying to fit custom elements into a well-known React lifecycle diagram style, yes?

I'm not sure the axes on this make sense though. The phases doesn't actually apply to all of connecting, updating and disconnecting. It seems like both axes are related to time, and so they overlap in meaning.

[AndyOGo]

@justinfagnani
Thanks for your reply:)
Almost yes, my intention is to visualize the lifecycle of custom elements and it's pitfalls and to encourage developers to actually carefully study the official specs.
Especially if a user comes from a functional and deterministic world, he would not expect that custom elements are asynchronous and non-deterministic.
Yes I took the fantastic React Lifecycle diagram as a basis.

That's correct, most stuff happens only within the upgrade or live phases.
Hmh, yes both axes are related to time by intention.

[justinfagnani]

The problem with both axes relating to time is that I think it makes the whole chart not make a lot of sense. Take a single column/callback, like "Disconnecting". It does not go through "Unknown", "Upgrade" and Live" phases, so what information is conveyed by having the vertical axis at all?

[AndyOGo]

Well it means that disconnectedCallback will only ever fire if the DOM node is live.

The other important fact, is the browser's parsing phase building a DOM tree eventually with yet unknown/undefined custom elements

[AndyOGo]

If you want to have proof why it's important to differentiate between these timing factors, have a look at this test page:
https://wc-connected-test.glitch.me/

[daKmoR]

https://wc-connected-test.glitch.me/

can you maybe explain this a little more... e.g. what is happening and what real-life impact that has? I looked at the code and I think it explains the timing issues you can have with your children but just by looking at the result it's not clear at all 🙈

so maybe add some explainers and consequences and definitely add a link to the source file so you can see in code what is happening... https://glitch.com/edit/#!/wc-connected-test?path=server.js:31:43

but I really like it :)

[AndyOGo]

@daKmoR
Thanks for your feedback, actually each test's title says exactly which DOM operations are being performed.

For details there e.g. this official issue (big discussion though):
https://github.com/w3c/webcomponents/issues/551

[daKmoR]

So in short you can never be sure that your dom child nodes are then when you are in your connectedCallback...

also, the description alone was not understandable to me...
so maybe placing the code as snippets before - that would be the best to follow along... a link would be a good start :)

don't get me wrong... I really like it and it shows what things you need to be careful about - however if someone has a problem like "I can't access my lightdom childen in my connectedCallback" => I would like to just send them the link and say "jup, for reasons see here: " but right now that won't work as the link itself is really hard to follow...

[AndyOGo]

@daKmoR
I understand, thanks for communicating that honest.

Exactly, you can't predict that all custom elements children will be there.
It depends a lot which method is used to create a custom element and at which time the custom element is created.

The glitch was created by Jake Archibald, you would need to get in touch with him.
Here is the project at glitch.com: https://glitch.com/~wc-connected-test
And here his user: https://glitch.com/@jakearchibald

I hope it helps you.