Is #hydration a fundamentally synchronous process? Is there value in including async operations in hydration? Is hydration sufficiently distinct from initialization?
I wrote some thoughts about this as relates to the `defer-hydration` #WebComponents community protocol. Would love to hear your thoughts!
https://github.com/webcomponents-cg/community-protocols/issues/48
@jaredwhite Yeah I am wondering if it would make more sense to have a separate community protocol for initialization.
I'm very strongly of the opinion that you should never be able to get a reference to an uninitialized object (I think this is sometimes called #RAII?) Unfortunately that ship sailed for web components a long time ago. Constructors are worthless in this context too (and terrible per https://blog.dwac.dev/posts/ctor/). So maybe a protocol around initialization would help, whether that is or isn't `defer-hydration`.
@develwithoutacause I had to introduce a special promise for my solution getting Turbo and Declarative Shadow DOM working nicely.
https://github.com/whitefusionhq/turbo-shadow
I think that's a different lifecycle than the one you're describing, but I'm pointing it out because I think in general we could use more promise-based lifecycle conventions.
Provides event handling and an HTMLElement mixin for Declarative Shadow DOM in Hotwire Turbo. - GitHub - whitefusionhq/turbo-shadow: Provides event handling and an HTMLElement mixin for Declarative...
@jaredwhite Yeah DSD is definitely missing some useful lifecycle methods. I had to do something similar in my #HtmlFragments experimentation, specifically for getting streaming to work correctly.
https://blog.dwac.dev/posts/streamable-html-fragments/#chunked-declarative-shadow-dom
I still maintain we need a hook to know when an element is parsed, but I feel like we're losing that battle.
Doug Parker 🕸️
Jared White (ResistanceNet ✊)