💡 RFC: Add support for client-side only component hydration

[tony-sull]

Background & Motivation

I want to be able to mark a component to only hydrate in the browser

Proposed Solution

<Counter client:only />

Possible solutions

<Counter client:only />

Alternatives considered

Wrapping browser - specific calls in import.meta.env.SSR or undefined checks

Risks, downsides, and/or tradeoffs

Will likely run into #642 since the children wouldn't be included in the server rendered DOM

Open Questions

Is there an easier way to allow this without partial hydration? Would something like Astro.props.browser do the trick?

Detailed Design

During SSR, any component with client:only hydration won't be rendered but will be prepped for client-side hydration as usual.

Good warnings are key here! If a component fails to render during SSR, log a good error message and recommend using client:only if the component depends on browser-specific APIs

Help make it happen!

• I am willing to submit a PR to implement this change.
• I am willing to submit a PR to implement this change, but would need some guidance.
• I am not willing to submit a PR to implement this change.

[natemoo-re]

client:only? And that's a good point about hydration, we'd need to render a placeholder deterministically, but I'm not sure how we'd do that since we're currently building the hash based on the generated HTML. Will think about this!

[FredKSchott]

Copying from discussion on Discord: https://discord.com/channels/830184174198718474/845430950191038464/865646524734111784

---
import {Fallback} from 'astro/components';
---
<Fallback>
  <MyReactComponent client:only />
  <MySpinner slot="fallback" />
</Fallback>

Not sure how feasible this is (i don't think it is, actually) but the idea of providing a placeholder/fallback via a slot is interesting!

[matthewp]

@FredKSchott you wrote client:load but I think you mean client:only here.

[FredKSchott]

Use Case

• D3 is a good example of a package that has trouble in SSR
• if I depend on d3 in a component that gets server rendered, that component breaks
• without this RFC, I have no way to send that component to the browser

RFC Discussion

• good error messages - if component fails to render, tell user about client:load
• Is 🐛 BUG: passing children via props does not work properly on React components #681 blocking? Not blocking, just related / an alternate solution.

Does this work without fallback support?

• a component can already render different on the SSR vs. the client

<div height="200" width="200">
  <MyReactComponent client:only />
</div>

• another proposal for fallbacks coming from @jasikpark

// Visual.tsx
import Fallback from "Fallback";
if (meta.env.SSR) {
  <Fallback/>
} else {
  let d3 = import('d3'); // https://javascript.info/modules-dynamic-imports
  d3.renderFancyVisual();
}

RFC Decision

• Approved!

[tony-sull]

We should make sure this will work with #877. I'm guessing support for combining hydration methods will be generic so client:only would bolt right on to any of the other hydration methods, but noting here just in case that RFC may impact the solution here

[matthewp]

@tony-sull Good point. That brings up, when should client:only by itself (without combinators) load? I would assume it would be equivalent to :load.

[jasikpark]

Maybe it shouldn't specify a loading strategy, though in effect the default would be on :load.. so you need to do both client:only and client:visible?

[tony-sull]

Yeah I hadn't thought at all about combining hydration modes until I noticed #877 in the RFC tracker. I also was thinking client:only would act the same as :load, and I guess it would combine with other hydrstors just like :load will as well

[matthewp]

Regardless, I think these are questions for #877 to answer, it shouldn't block client:only