Re: [whatwg/dom] customElementRegistry.initialize should provoke custom elements to upgrade (Issue #1408)

justinfagnani left a comment (whatwg/dom#1408)

I'm having a hard time thinking of cases where I'd want to initialize but not upgrade a shadowRoot. If there were a case, then I could also just not initialize it yet.

Initializing and not upgrading leave the root in a state where new elements are customized but existing elements are uncustomized. That seems _very_ fragile and prone to errors if custom elements are doing any kind of property access or firing events. I would think we'd want to avoid such inconsistent states if possible.

One oddity here is that `upgrade()` reaches into nested shadow roots and `initialize()` doesn't. That means that with the current APIs, and in the common SSR case of a tree-of-trees of declarative shadow roots using scoped registries, that you'll get repeated upgrade passes over the shadow roots. Every root will get an upgrade pass shadow_depth number of times. And you can't short circuit the upgrade passes based on whether the root is connected because elements can have this state of being defined, non-upgraded, and connected. So every upgrade() call has to walk the whole tree-of-trees.

afaik this state of connected, defined, but non-upgraded is either new, or newly visible to regular script. Maybe previously it was only visible in CE constructors during an upgrade pass?

It seems like it might be better for performance to eliminate the repeated and redundant upgrade passes by making `initialize()` upgrade, but only the current root and not any nested shadow roots.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1408#issuecomment-3363458783
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1408/3363458783@github.com>