[defer-hydration] Async hydration about community-protocols

[justinfagnani]

I don't think the use case you're taking about or the example your posted is really hydration in the sense that I know it. You essentially have a component that's already "hydrated" or just doesn't need hydration.

One case where defer-hydration would be critical is if instead of fetching data based on a user-id attribute, it fetched based on some non-serializable property set by the parent during the parent's hydration. Then you would want to wait until you had the data from the parent to begin the fetch so that you potentially didn't fetch twice and throw away one result. The component could wait to fetch if defer-hydration is present and fetch when it's removed. This would probably look like it deferring it's normal connected or attribute-changed logic.

Regardless, you have a component that async fetches data, and therefore all of the APIs based on that data need to be designed with that in mind. Whether getFriends() is async, or there's a promise on the component that resolves when it's ready, etc., would be up to the component. Presumably it has to answer all those questions for client-side rendering too, so there's nothing defer-hyderation could do to universally answer them.

[dgp1130]

I don't think the use case you're taking about or the example your posted is really hydration in the sense that I know it. You essentially have a component that's already "hydrated" or just doesn't need hydration.

I can see that await fetchUser is arguably not hydration, but do you also think Number(this.getAttribute('user-id')!) is not hydrating? The current defer-hydration proposal is kind of vague on the definition of "hydration" and I proposed a few different interpretations in my first comment. How do you define that term for the purposes of defer-hydration?

One case where defer-hydration would be critical is if instead of fetching data based on a user-id attribute, it fetched based on some non-serializable property set by the parent during the parent's hydration. Then you would want to wait until you had the data from the parent to begin the fetch so that you potentially didn't fetch twice and throw away one result. The component could wait to fetch if defer-hydration is present and fetch when it's removed. This would probably look like it deferring it's normal connected or attribute-changed logic.

Sure, if you believe that is a more compelling use case then I agree async hydration could be just as relevant there. I created a new Stackblitz which demonstrates this exact use case.

I don't personally see defer-hydration as intrinsically tied to top-down hydration or non-serializable inputs and I don't think this particular issue is all that affected by it.

Regardless, you have a component that async fetches data, and therefore all of the APIs based on that data need to be designed with that in mind. Whether getFriends() is async, or there's a promise on the component that resolves when it's ready, etc., would be up to the component. Presumably it has to answer all those questions for client-side rendering too, so there's nothing defer-hyderation could do to universally answer them.

I will point out that not all components will support client-side rendering. Server-only components which are progressively enhanced on the client that don't necessitate a re-render step are perfectly viable today. An async form of defer-hydration could be exactly what such components need to properly interoperate.

That said, I do agree client-side rendering has a very similar initialization problem, and maybe that's a signal that this is something which should be tackled independently of defer-hydration. Certainly I would want any general solution to initialization to also have a good story as relates to hydration and server-only components in particular.