Allow using the server build when ssr: false

[rossipedia]

The ssr option is a bit overloaded:

• Yes, it disables server side rendering
• It also completely eliminates the server build and prohibits using loader or action module exports.

I propose that we should still be allowed to use the server build when ssr: false.

• It should not delete build/server (or whatever it's configured to be)
• It should not error when a server-specific module export is detected
• You should be able to specify where that server build is going be hosted at (ie: the origin of server requests). The default behavior will inherit location.origin, which the way things behave today.

You still get a fully static build/client/* folder, and can completely ignore build/server/* if you use nothing but clientLoader and clientAction in your routes.

This is the taditional React Router "SPA mode".

But with this change, you can still use loader or action if you want.

Why would I want that

These changes give you a fully static client build, hostable anywhere, that integrates seamlessly with a server build that provides loaders and actions for that client build, that can be hosted somewhere else.

All while keeping your client and server code colocated in the same module file like we're used to currently.

This unlocks RR's server-side route module convention for scenarios like:

• Electron Apps that needs to have all the HTML shipped with the executable
• Social platform games such as an HTML-based Facebook game. Facebook requires that it hosts the HTML, and only allows specific CDNs for the static assets, but games are free to make API/fetch calls.
• or you simply don't want to (or can't) support SSR, but still want to use React Router's server-side features (loaders/actions) to keep things colocated with your UI.

Customize server origin

In order for this to be useful for more than the simplest cases, there would need to be a way to specify the origin of server requests, separate from the origin of the UI.

In the Steering Committee we've been talking about potentially adding a fetch prop to HydratedRouter (which would be a separate discussion/proposal), which would allow you to customize the fetch implementation that React Router uses when performing data requests.

I think this is the most straightforward way of supporting a separate server origin, rather than adding any new configuration options to react-router.config.ts.

It would look like this in your entry.client.tsx:

import { startTransition, StrictMode } from 'react'
import { hydrateRoot } from 'react-dom/client'
import { HydratedRouter } from 'react-router/dom'

function getServerUrl(input: RequestInfo) {
  // Resolve this however you want. You could use a build time constant such as
  // `import.meta.env.SERVER_URL` or anything you prefer.
}

startTransition(() => {
  hydrateRoot(
    document,
    <StrictMode>
      <HydratedRouter
        // Same signature as global fetch:
        fetch={(input, init) =>
          window.fetch(getServerUrl(input), init ?? input)
        }
      />
    </StrictMode>,
  )
})

This proposal would end up being dependant on customizable fetch being added to HydratedRouter.

[alexanderson1993]

I like how the server customization automatically falls out of the fetch implementation proposal.

[rossipedia]

yeah that's definitely @jacob-ebey's influence there making sure I don't overcomplicate things 😅

[brophdawg11]

PR: #15601

[rossipedia]

aaaand merged ✊