Back

@develwithoutacause oooh—I would love to see `defer-hydration` support! That sounds like exactly what is needed to solve this in a much better way

@develwithoutacause (subscribed and upvoted)

I don’t think it will do much until it’s natively available in the platform though right?

@develwithoutacause well, wait—I think I understand what you mean. If component libraries have implemented this (and it seems like Lit has?)—I can add support for `defer-hydration` today and it will work in those libraries

@zachleat Yeah, it's a "community protocol", so any component / component library can implement it, there's nothing browsers *need* to support.

My own library in that repo respects `defer-hydration`, so `is-land` just needs to remove the attribute from any child nodes, which I think is a reasonable thing for it to do?

@zachleat Not sure what the default behavior should be, but maybe don't replace the tag name if the node has `defer-hydration`? If it has that attribute then you have a pretty good reason to believe it won't do anything until the attribute is removed by `is-land`.

@develwithoutacause yeah! I love that! I would also like to see it as a supported feature in the platform too

@zachleat Me too, though TBH I'm not sure what it would really look like as a supported feature. Maybe an attribute which tells the browser "don't upgrade components in this subtree"?

@develwithoutacause yeah I think it could even be simpler: don’t upgrade this specific element

@zachleat That's basically what `defer-hydration` does, it just requires the component to implement that behavior (which isn't great I admit).

I do feel like when it only applies to a specific element, it requires you to put `defer-hydration` on everything except the top-level node, which is easy to mess up. It's also implementable in userspace via `attributeChangedCallback()` like `defer-hydration` does, whereas a subtree approach can't be.