Partial hydration attributes are exclusive right?

[daKmoR]

hey there 👋

I am currently looking into how to best implement partial hydration in a different project and I wanted to see if there might be some overlap here.

While looking at it I get a little confused about the "ssr/render/client/server/..." options?

With the current API users could make "invalid" code by accident?

<MyComponent client:idle client:visible />

what wins now? idle, visible?

Is there a particular reason it's multiple boolean attributes and not one attribute with a value?

If there is none then I'm wondering if a single attribute might make sense?

Some possible ideas

How would something like this feel? use a single attribute like render-mode (or ssr-render, or ssr or ...)

<MyComponent render-mode="server" />
                    <!-- 👆 this is the default so it can also be written as <MyComponent />  -->
<MyComponent render-mode="client" />

<MyComponent render-mode="hydrate:idle" />
<MyComponent render-mode="hydrate:visible" />
<MyComponent render-mode="hydrate:@media screen and (max-width: 320px)" />
                             <!-- 👆 only hydrate on small screens / mobile -->

[natemoo-re]

This is a great question—thanks for asking! 😄

For historical context, when we started working on partial hydration, we outlined three initial modes (load, idle and visible). They very much appeared to be exclusive, meaning client:* could be thought of like an enum. server was assumed to be the default.

As time progressed, we saw requests for more granular control. client:media was introduced to restrict loading when particular parameters were met. client:only was introduced to disable SSR but allow the component to render on the client.

If I'm reading your question correctly, then "hey why can't I use (client:visible AND client:media) or (client:only AND client:idle)?" is totally valid and a bit weird! We were bound by some early API decisions that proved to be incorrect, then we avoided revisiting the issue because we already caused some early churn by migrating from a magical idle attribute to a namespaced client:idle directive.

I'd really like to revisit this and see if there's a good API (probably similar to CSS at-rules?) that could handle the combinatorial nature of the hydration primitives we have.

[natemoo-re]

I'd love to hear @jonathantneal's thoughts on a possible syntax for this. Am I right in thinking that @media might provide a concrete syntax for combinatorial problems like this?

I also know that @Holben888 put a lot of thought into adopting Astro's partial hydration for Slinkity and might have some thoughts on what we got right (or wrong).

[ghost]

@natemoo-re I indeed have thoughts about this one! We have an RFC from the early days of Slinkity on composable hydration modes. And yes, I still want to see it through 😁 Curious about your thoughts on this: slinkity/slinkity#20. I'm sure the ship on "use hydrate instead of client" has sailed, but I outlined composability on the comment thread.

[daKmoR]

thank you for the pointers - that really helped me refine it more... I'm now more convinced that a single attribute makes more sense... and that for hydration multiple "options" should be combinable

I posted a reply to slinkity/slinkity#20 (comment) and it's sort of the outline for the hydration I wanna see at some point in next major version of modernweb-dev/rocket#302

The gist of it is this

Example	Description
render-mode="server"	non interactive stuff like layouts or graphical components (= default)
render-mode="hydrate"	most components should just hydrate as soon there is a free slot in the main thread
render-mode="hydrate:onIdle"	same as 👆
render-mode="hydrate:onRender"	above the fold element that should become interactive as soon as possible
render-mode="hydrate:onMedia(@media (max-width: 320px))"	mobile burger menu that triggers a drawer for navigation (only hydrate on screens smaller then 320p)
render-mode="hydrate:onMedia(@media (min-width: 640px)).onClick"	chart that only becomes interactive on desktop after a click
render-mode="hydrate:onMedia(@media (prefers-reduced-motion: no-preference)).onClick"	a visual animation that plays on click only if there is no prefers-reduced-motion
render-mode="hydrate:onVisible.onIdle"	heavy chart that becomes interactive when element becomes visible
render-mode="hydrate:onVisible(100px)"	heavy chart that becomes interactive when element + 100px padding becomes visible
render-mode="client"	components that do something that can not be server rendered (for example need to access cookies or localStorage)

but I can see that this is probably not something that astro wants to touch because of backward compatibility...

[ghost]

☝️ A bit irrelevant for Astro, but I'm considering switching Slinkity's API to this approach. Seems to solve a lot of naming issues we were getting ready to have, particular the server -> hydrate -> client progression outlined here.

[ghost]

I agree that Astro should support multiple client directives, but maybe not with an overhaul to the API as proposed here. I'd look to Vue's custom directives for inspiration here. They have a notion of "modifiers" you can access via dot . syntax. For instance, we could do the following:

<Component client:idle.onMedia(min-width: 400px) />

I could even imagine checks to prevent impossible combinations (if not from your editor, at least from the CLI console). For instance, we could prevent this:

<!--Cannot chain "visible" from the "idle" directive-->
<Component client:idle.visible />

We could even introduce helpers for to all race conditions. For instance, either show on media or on click of some button (note buttonClick is purely theoretical):

<Component client:buttonClick.or.visible />

A lot of kinks to work out of course. @natemoo-re are there any existing RFCs on this subject that are worth linking as well?

[plutoniumm]

One addon so to say on this I would request is dynamic allocation of hydration, if I map an array onto a component with hydration marked on it I would probably prefer rendering only the first few as is and the rest when in viewport so say something like

<!-- some form of array map -->
<Component {index<6 ? client:load : client:visible} />

A bit like how some frameworks do for {...props};
Enabling this form of "hydration calculation" might also solve maybe a few other problems here and there