appreciate your feedback for custom element diagram

[AndyOGo]

Hy @WebReflection

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.

[WebReflection]

I wish it was that simple, unfortunately it isn't.

If the node is already on the document, and the document is fully parsed, and you define your custom element, there are no issues in reading, or even modifying, the node within its constructor, or within its attributeChanged callback.

However, this is not the case if the element is pre-defined and encountered while parsing the document.

In any case though, even the connectedCallback isn't safe to modify the node content, because the connected is invoked synchronously on node tag opened, but not necessarily on node tag closed.

Accordingly, it's basically impossible through Custom Elements to be sure that a node content can be modified, and the only safe option to mutate such element is to use its Shadow Root element instead of the regular content.

Or ... you need to define your components on document loaded.

Or ... you need an indirection that tries to fix all these issues for you, like https://github.com/WebReflection/html-parsed-element#html-parsed-element does.

[AndyOGo]

Thanks for your fast, detailed and clear feedback.

Personally I'm still concerned with (what I would call it) the asynchronous nature of custom elements. Do you agree with this wording?
In my opinion this basic asynchronous concept introduces most of the complexity involved with ce.
And I'm still thinking how to express this factor clearly within the diagram.

Thanks for the link, I will look into it.

[AndyOGo]

PS: great link, indeed connectedCallback and the fact that it can be called multiple times is not deterministic.

[AndyOGo]

This example below of this part of the spec also clearly demonstrates the "queued" integrity issue of connectedCallback:
https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance

[WebReflection]

Personally I'm still concerned with (what I would call it) the asynchronous nature of custom elements.
Do you agree with this wording?

I agree so much that I've proposed more reliable alternatives https://itnext.io/a-wicked-custom-elements-alternative-6d1504b5857f

[AndyOGo]

Really Awesome. You have just eliminated this asynchronicity design issue 🚀

IMHO I'm having a hard time to argue that custom elements are fragile and forces all developer's to rethink their synchronous paradigms to async 😱
I will try wickedElements

[AndyOGo]

In general I think that the fundament challenge is, that HTML and HTTP was never designed for components nor apps. It was made for documents being represented by hypertext.

[AndyOGo]

@WebReflection
I made some updates:
https://andyogo.github.io/custom-element-reactions-diagram/