Re: [w3c/webcomponents] Custom Element - untrackable upgrade (#671)

> Seems like whenDefined just resolving when all need-to-be-upgraded elements have been upgraded would prevent us prematurely setting properties.

not at all. You can set properties to any DOM node, regardless it will be a Custom Element or not, which is the reason `.whenDefined` became handy, to interact, or to create, those kind of nodes once the class is registered, which could, or actually could never, happen.

>From a _hyper/lit_HTML perspective, we parse a template content as soon as injected and without any guarantees of Custom Elements definitions.

We can just guess via element `nodeName` sniffing and nothing else (pretty much what browsers can do until there is a definition), if an element might be a CE candidate or not, and WeakMap is the only savior here.

Moreover, some element might have observable attributes that would involve prototype setters once invoked, and if such invocation should happen only once the element is live, then let it be like that, our code wouldn't care less and logic will move once live, instead of always.

However, for non DOM related use cases, something I believe nobody here is interested in hearing, having a `whenDefined` that upgrades before everything live and resolve once everything live is upgraded, granting that from that time on every Custom Element ever would be synchronously available even in templates, the `whenDefined` calling not at class definition but at live nodes upgrade complete, granting synchronous upgrades from that time on might be a valuable solution.

Although, what @rniwa said didn't sound promising:

> we came up with many convoluted solutions and we disliked them all

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/671#issuecomment-335570525