💡 RFC: Support async rendering of react components

[trashhalo]

Background & Motivation

Provide clean path to pull in server side data during env.SSR inside functional react components. No defined path to accomplish this right now and the defined renderer does not support an async call signature for react.

Proposed Solution

Possible solutions

• Add react-ssr-prepass to the existing react renderer https://www.npmjs.com/package/react-ssr-prepass
• Wait for React 18 and create a react 18 renderer https://reactjs.org/docs/concurrent-mode-suspense.html
• Custom solution like: https://nextjs.org/docs/api-reference/data-fetching/getInitialProps

Detailed Design

No response

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]

This would be very cool! I'm in favor of adding react-ssr-prepass to the existing renderer.

[trashhalo]

I have a branch with this integrated. https://github.com/snowpackjs/astro/compare/main...trashhalo:react-ssr-prepass?expand=1 I wrote a test case too!

I hate the throw+external cache backflip you have to do to get this to work. It's possible there are better ways to do this. Here was feedback the author gave me. FormidableLabs/react-ssr-prepass#72

I'd recommend if developers have to do something like that to make suspense pattern do its magic then we try and identify an existing or write a hook that encapsulates some of the boilerplate.

[drwpow]

RFC Call decision: we really love this idea! And there are a lot of people that have expressed interest for this approach. But withreact-ssr-prepass being experimental/temporary, and React 18 possibly coming, this also feels like a lot could change in how this gets implemented.

So for that reason, we’d like to see this implemented as a third-party renderer first which it looks like @trashhalo has already started. I’ll create a thread in #ideas-and-suggestions discussing developing this renderer:

The goal long-term is that if the renderer stabilizes, and seems to be more future-proof, we could decide whether or not it becomes a part of the core React renderer, or we start to maintain it, or, who knows? But either way we’ll need to iterate on it a bit first.

[trashhalo]

Wow I'm honored that you all discussed my little ticket on the call! I'd be happy to contribute code to this initiative.

[trashhalo]

https://github.com/trashhalo/astrojs-renderer-react-next repo up and published to npm!

[matthewp]

Love it!

[matthewp]

As the renderer is now out I think we can close this issue. Looking forward to seeing how this renderer works out for everyone and we can revisit what the default renderer does in the future.

[omidantilong]

Hey @trashhalo and @matthewp (and @natemoo-re again!) 👋

Just wondered what the status of this project is as I'm guessing this was for a much earlier version of Astro (and React). As far as I can tell, Astro still won't render async function components, unless I'm missing something... If you have any insights, it would be greatly appreciated ❤️

EDIT - Well I now realise I've spent too much time with Next.js and hadn't kept up with where RSC is actually at...

[mariansam]

Hi @omidantilong, I just tried creating an async function ServerReact React component and using it in an Astro component as <ServerReact /> and it gives me Objects are not valid as a React child (found: [object Promise]). If you meant to render a collection of children, use an array instead. What did you end up doing? Is there any way you managed to run React async components in Astro on the server?

[omidantilong]

I didn't get any further with it in the end, since Astro added the container API and unit testing Astro components became possible. Maybe there'll be some progress on this once RSC is fully stabilised :)