New blog post:
Use defer-hydration in your Web Components for… well, deferred hydration.
https://www.zachleat.com/web/defer-hydration/
(now supported in <is-land> v3.0!)
Inspired by @develwithoutacause
Zach Leatherman 1818 replies 1515 likes88 reposts Original on Mastodon18 replies
@zachleat I still don't understand the use-case for wanting to delay hydration (as I stated in the proposal) 😀
@matthewp I’m guessing you’re all-in on SSR?
I think some PE scenarios require heftier DOM changes—I’ve talked a bit about the tension between SSR and PE before—I think this assists nicely there
@zachleat I like to think I'm a pragmatist so I'm not really all-in on anything.
But when I say I don't understand I really do mean I don't understand, not that I disagree with it. I don't understand what scenario exists that you would want a component to not hydrate until you do something else. That's what I asked in the proposal thread but never got a reply.
@matthewp I’m confused—isn’t that the point of islands? Arbitrary conditions on “hydrating” child content?
@zachleat Ok, so you are using defer-hydration so that if you have a on:idle and on:visible on the same page, the visible one will continue to be delayed.
To me, I think of the directives as "fastest wins" and I don't necessarily want 2 of the same components to hydrate at different times.
@zachleat It's more of wanting to delay the loading and JS execution. Once that's happened then you might as well hydrate *all* of the component instances. I haven't thought of a reason to not hydrate a component who's code is loaded.
@matthewp ahh, I see. Yeah I’m not sure I agree with that (yet?)
The implementation I added for `<is-land on:idle on:visible>` is that it won’t remove `defer-hydration` attribute until both conditions are met—I’d absolutely want the island to be in full control over its children (even if another distinct island defines the same custom element)
@zachleat From my perspective, a web component should only control its shadow dom and <slot>. If it is controlling what is inside of that slot there's a coupling problem. There are some rare exceptions.
@matthewp I guess I’m making the case that `<is-land>` as a web component is an exception to that rule!
@zachleat Yeah, for sure. I still don't see the use-case though 😆 What is the scenario where you want to hydrate <my-component> in one island but delay its hydration in a different island?
@zachleat I think one difference is you are thinking about it from the perspective of the author of <is-land> and I'm thinking about it from the perspective of the <my-component> author.
As a component author, conforming to the <is-land> wishes isn't enough of a reason. I need a real use-case.
@matthewp it’s ok! We can disagree! 👍🏻
@zachleat Of course, but I'm not sure what we're disagreeing on. Is the reason to delay hydration just because that's what <is-land>'s API wants to happen? I'm genuinely just trying to understand.
I like to think about WCs in terms of "what would native elements do". Would a native element defer hydration based on a blanket attribute? I don't think so! They might delay it given a specific reason, but that reason is part of the element's API, not a global option.
@matthewp I don’t think it’s much different than defer for script or loading for img!
@zachleat it's different in those are not global attributes. They are APIs defined by those elements, and have specific use-cases and behavior. Neither defer forever. Link tags don't respect those attributes because it's not part of the <link> API.
@zachleat As a nit, the article calls this a "community-agreed-upon draft standard", but it's not community agreed upon. It's an open proposal with some (but not a lot) of feedback. Not yet merged and agreed upon.
