RR7 requires HydrateFallback and clientLoader to disable SSR

[flodaniel]

I'm using React Router as a...

framework

Reproduction

Had to provide my own repo as stackblitz does not support node 20 which is required for RR7: https://github.com/flodaniel/rr7-ssr-bug

1. Attempt to disable SSR by exporting a HydrateFallback
2. Observe the crash window is not defined
3. Adding an empty clientLoader export resolves the issue: This should not be necessary.

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    vite: ^5.1.0 => 5.4.14

Used Package Manager

npm

Expected Behavior

SSR is disabled as soon as a HydrateFallback is exported

Actual Behavior

SSR is disabled only after a HydrateFallback AND a clientLoader is exported

[timdorr]

The example you gave is using Remix, not React Router. Can you update that?

[flodaniel]

The example you gave is using Remix, not React Router. Can you update that?

Oh no. I am sorry. I was just using the Stackblitz link in the template. I will try to find a RR7 template and add it there. Stackblitz is still running on node 18 and RR7 needs v20 :/

[flodaniel]

@timdorr updated the issue with a link to a public repo i created: https://github.com/flodaniel/rr7-ssr-bug. Most of this is copy-paste from a starter template and only app/src/routes/nossr.tsx is relevant.

[timdorr]

Note that you can use CodeSandbox instead, as it supports newer versions of Node. Sorry about directing you to the wrong tool.

I guess I'm not understanding the use case here. Why do you want to provide a HydrateFallback without a clientLoader?

HydrateFallback is only rendered by the server (or during a prerender) to put something into the output HTML that will later be replaced when the clientLoader can run. It is logical that you wouldn't have a HydrateFallback without a clientLoader, otherwise you would never replace the HydrateFallback content.

[flodaniel]

My goal is to just completely disable SSR. The only way I have been able to get that working was by adding both. I do not actually have anything to load inside by clientLoader.
The idea is that disabelling SSR will allow us to migrate a larger codebase slowly to fully support SSR. In an ideal world (for us) the RouteConfigEntry would allow to override the global ssr setting.

[timdorr]

Unfortunately, you can't do that. SSR is enabled/disabled globally for an app. Regardless, if you're trying to keep the app in SPA mode, you need to use clientLoader if you're going to have a loader for a route.

The HydrateFallback won't be used if you don't have SSR enabled, so including it isn't important. But if you do include it, it requires a clientLoader to function.

[brophdawg11]

SSR is disabled only after a HydrateFallback AND a clientLoader is exported

This is expected behavior - think of the HydrateFallback like a <Suspense fallback>. The suspense fallback only renders when the suspended data/UI is not yet ready. It does not render if the suspended data is available.

The HydrateFallback only renders if that route (or any of it's children) are waiting on data that won['t be available until the app hydrates and runs client loaders. Without a clientLoader you're telling RR that there are no data requirements for this UI so the UI can render immediately.

I think it's a fine approach to use an empty clientLoader to tell a route not to render on the server.

[sarendipitee]

Unfortunately, you can't do that. SSR is enabled/disabled globally for an app.

This is very unfortunate indeed. "My way or the high way".

I have a large project with many routes that RRv7/Remix-esque SSR routes and loaders work great on.

BUT I also have a couple very complex routes that have their own isolated state loading and management that render the data into <Canvas> depending on configuration that I can only access client side. What's the point of having all that data load on the server just for it to re-run on the client after its immediately invalidated?

Not having an ssr opt-out hatch is so inflexible for problems people are trying to solve 🥺.

[brophdawg11]

It would be a very bad idea if the presence of a HydrateFallback disabled SSR. A very common pattern is to put a HydrateFallback on the root route that serves as a global "initial loading indicator" for any child routes that have clientLoaders. If you access a path where all matches have only server loaders, the page can be fully SSR'd. If you access a path where any match has a clientLoader - it bubbles up and renders the root HydrateFallback.

If the behavior was instead "SSR is disabled as soon as a HydrateFallback is exported", then that would result in those use cases never SSR'ing because the root route always matches.

Not having an ssr opt-out hatch

We do have an ssr opt-out hatch - clientLoader. Or you could also leverage ClientOnly in your component.

[sarendipitee]

@brophdawg11

is exactly what I have been looking for! Thank you. RRv7 is my first foray into Remix-world so it's the first time I'm even seen that repo mentioned anywhere.

There are just some scenarios where you still want the route to be SSR but a child in the route you don't even want evaluated on the server. So depending on clientLoader isn't really an option to avoid rendering the specific child tree whatsoever on the server.