Server-side rendering and preloaded state with React 18

[azangru]

I am looking for advice about custom server-side rendering of React app that uses redux. I know the common advice is just to use Next; but I hope I can find here brave souls who have tried setting this up from scratch without a metaframework.

In a discussion in React Working Group that introduced the new Suspense SSR architecture for React 18, Dan provided a demo of a simple server-rendered React app. The interesting bit about that demo — apart from the use of server-side Suspense, and of the renderToPipeableStream api — was that React in it controlled the whole html element. I think, the first time I saw this approach was when Remix guys were describing their setup half a year or so prior to Dan's post; and at that time, they confessed that they were bending the rules. Several months later, this technique seems to have received the official blessing of the React team.

However, if React is in control of the whole html element, then, I suppose (I haven't tested this assumption; so may be wrong), during the hydration phase, it will want the html markup that arrives in the browser from the server to be identical to the DOM tree it generates at hydration. If this is the case, then how should we pass the redux state from the server to the client? Even now, Redux docs are suggesting suggesting a script tag that sets the stringified redux state the window.__PRELOADED_STATE__ field. If we use the approach shown in Dan's demo, would we have to somehow replicate this in the Html React element on the client?

Do you know of a simple SSR demo that follows React 18 idioms and uses Redux?

[markerikson]

Unfortunately, neither Lenz or I actively use SSR, so we're not experts here at all.

There's been a few related discussion threads scattered through our repos:

• React 18 and streaming SSR react-redux#1874
• RTK Query ServerSideRendering #1184
• How to incrementally hydrate Redux across page fragments during initial load? #1820

From what @Ephem said in a couple places, my impression is that Redux isn't a good match for streaming, but I honestly don't know much beyond that.

[Ephem]

Not sure if I'm brave or stupid, but I do have some experience with this so here it goes. 😄

The interesting bit about that demo — *** — was that React in it controlled the whole html element

To me this is the wrong thing to focus on, I don't think it really matters if React owns the entire html or if you have some serverside template that owns the root html and you put React inside it. The two approaches will look different in the details, but they both work the same really.

If we use the approach shown in Dan's demo, would we have to somehow replicate this in the Html React element on the client?
Do you know of a simple SSR demo that follows React 18 idioms and uses Redux?

Yes! It's not recently updated, but I previously put together an example here that might be helpful, based on Dan's sandbox: https://codesandbox.io/s/react-18-redux-ssr-npltr?file=/src/Html.js

From what @Ephem said in a couple places, my impression is that Redux isn't a good match for streaming, but I honestly don't know much beyond that.

@markerikson Well, it depends I'd say. As I mentioned in this comment over in react-redux#1874:

Streaming the result of the server render is fine as long as you don't start hydrating the markup on the client until after you have hydrated the Redux store fully. The thing that might be tricky to implement in Redux is incremental hydration, where parts of the state is hydrated at different times.

This is still true, I'd say progressive/incremental hydration and Server Components are tricky to support with Redux today (but with the low level APIs Redux provides it might actually be possible to get working in userland, but very complex to get right), but "regular" React 18 SSR or even streaming SSR as shown in the sandbox above is no problem.

For the more complex cases (SCs etc), it's still very early days, I'm sure we'll see a lot happening in this space the next 6 months or so. 😄

[azangru]

To me this is the wrong thing to focus on, I don't think it really matters if React owns the entire html or if you have some serverside template that owns the root html and you put React inside it.

Just to explain the reason that I am focusing on React's control of the whole html element — I would like to remove the dependency on the loadable-components package, because it was created when React.lazy wasn't supporting server-side rendering, and has kinda got stuck with pre-18 versions of React since then, and this is now showing up as a warning in my npm output. While I am at it, I would also like to remove the dependency on react-helmet-async, because, as far as I understand it, it served it purpose before React attempted to control the contents of html head element; but now React seems to be capable of doing this on its own.

I'll go and study your codesandbox example now. Thank you!