ssr flag is ignored in react-router v7

[igortas]

Hi,

Why react-router starting in SSR mode, besides the flag is set to false in react-router.config.ts.

import type { Config } from '@react-router/dev/config';

export default {
    appDirectory: 'src',
    ssr: false
} satisfies Config;

I'm getting:

[vite] Internal server error: window is not defined

I'm using pnpm v9.13.2
Node is on version 23.3.0
React 18.3

[heikkilamarko]

Hi. We faced these errors as well with the same configuration when migrating to v7. To resolve this, we moved all the window-related code, such as localStorage calls, into functions invoked by clientLoader and clientActions.

Our app is a PWA that uses Vite PWA. It seems that @react-router/dev does not work well with it, so we decided not to use it and instead followed our existing approach (createBrowserRouter + RouterProvider) documented here: React Router: Custom Framework Integration

Based on my initial impression, the new Framework approach may not be the best choice for building a pure SPA or PWA, particularly if you don't intend to use SSR in the future. The Custom Framework approach feels more straightforward and less limiting.

[igortas]

@heikkilamarko My idea was go upgrade our codebase with client loaders, to clean a bit some components, and definetly make the app SSR ready after that. Thanks I'll try to experiment with the link u provide me, I've ommited in the docs.

[leonardbiofi]

Same issue on my side. I had just migrated from react-router v6 to react router v7 using the framwork approach.

However my component that were supposed to be only client renderer are failing because of that. I have set the ssr flag to false but it does not work.

Any idea ?

[igortas]

@leonardbiofi I've set the ssr flag in vite, I had some imports that were making problem. Looks like RR is running in server mode when app is starting...

	ssr: {
		optimizeDeps: ['lodash', 'exceljs', '@mui/*'],
		noExternal: ['lodash', 'exceljs', '@mui/*']
	},

[leonardbiofi]

I think I will not adopt the framework mode before all of this get more stable. Anyway I am currently using a Auth SPA, so server side rendering is not really advantageous to me. I just wanted to leverage the automatic bundling per routes which I think was a nice feature. I'll wait a bit longer that all this gets less experimental.

[karam1ashqar]

i have the same issue, i feel like i'm missing something

[ryanelian]

Seconding this.

I feel like when SSR is set to false, the application should not render anything below the Layout exported by the root.tsx

The default-exported Page by the root.tsx may be unsafe to render by the SSR, such as it may use window API or other browser-only APIs not available in Node.js

[brophdawg11]

FWIW this is exactly what it does - but due to the way vite bundles the routes into the server build it flattens module-scoped stuff in route modules into the module scope of the server build, so non-SSR-friendly aspects of child routes still end up being evaluated when importing the server build. We fixed this in #13023

[martpie]

I am also getting 15:31:23 [vite] (ssr) Error when evaluating SSR module virtual:react-router/server-build: when trying to build a SPA.

I am building a UI for a Tauri/Electron app, I can not have any SSR, even for development. This effectively fully blocks any migration to v7 beyond the Vite plugin setup (I was using RouterProvider).

I think this is worthy of a bug report?

[R-Bower]

I second this and have run into the same issues. I'd also like to be able to switch to the HashRouter in framework mode.

[vnyb]

I have:

vite.config.ts

  ...
  build: {
    ssr: false,
  },
  ...

and

react-router.config.ts

...
  ssr: false,
...

However, Vite still tries to build the SSR bundle:

...
$ npm run build
vite v5.4.11 building SSR bundle for production...

This change solved the problem:

--- a/package.json
+++ b/package.json
    ...
   "scripts": {
-    "build": "cross-env NODE_ENV=production react-router build",
+    "build": "vite build",
     "dev": "react-router dev",
-    "start": "cross-env NODE_ENV=production react-router-serve ./build/server/index.js",
     "typecheck": "react-router typegen && tsc"
   },
...

[igortas]

@vnyb Still not, as RR7 still runs the app in SSR mode. If u have libraries like lodash, mui, they give u headache, and of course window object if u need that object early in the bootstrap of the client app. One word this is mess. Lets switch to TSR, lets see that crap how behave for dead spa app migration.

[R-Bower]

This is a big blocker for me as well. This is the issue: https://reactrouter.com/how-to/spa#important-note

React Router will still server render your index route to generate that index.html file. This is why your project still needs a dependency on @react-router/node and your routes need to be SSR-safe. That means you can't call window or other browser-only APIs during the initial render, even when server rendering is disabled.

However, in modern Electron apps, the recommended approach for IPC is using their contextBridge:

// preload with contextIsolation enabled
const { contextBridge } = require('electron')

contextBridge.exposeInMainWorld('myAPI', {
  doAThing: () => {}
})

The above code snippet augments the window global with the electron api. Then we can access it from the React app as follows:

// use the exposed API in the renderer
window.myAPI.doAThing()

This is a hard requirement for my desktop apps. Is there any way to disable the initial pre-rendering?

[rolanday]

Where is the RR team to comment on this issue. Very concerning. It leaves the impression that the RR team is over-indexing on SSR (at cost of SPA). I had high hopes for RR7 but, for SPA apps, TSR is starting to look like the better option.

[bholmesdev]

+1, been burnt by this using several web APIs, including AudioContext and SpeechRecognition. I would switch to "library mode," but this gives up the clientLoader utility that I really enjoy

[einarq]

I read somewhere in the docs that even with ssr:false, the components will still render on the server. Quite confusing.

Happily using createBrowserRouter on an older SPA, so that’s a viable approach if all you want is the loaders.
Hopefully createBrowserRouter won’t suddenly get deprecated…

[andrioidApacta]

I suspect this behavior is intended so prepare everyone for the possibility of SSR; but the documentation could be much clearer as to what "SPA mode" means for the framework.

I'm not at the goal-line yet, but I've managed to get most of our libraries (ApexCharts was the worst) to work by using client-only files (e.g. .client.tsx) and the <ClientOnly /> component from remix-utils. Unfortunately this sort of meta-work isn't prioritized by my employer (understandably), but if I get it working I'll submit a PR for the docs.

[brophdawg11]

@bholmesdev clientLoader is just "framework mode"'s version of loader in the hydrated app. You can still use loaders, actions, fetchers client side when using library mode via RouterProvider.

This issue of non-SSR-friendly stuff in routes below root is fixed by #13023 though so that should ease framework mode adoption.

[rolanday]

As suggested above, custom framework mode will get you what we had in RRv6, which is client-side routing w/ option to run a client side loader. Even then there are some oddities such as referring to fallback element as hydrationFallbackElement, which is a real head-scratcher when you're building a SPA (#12687 (comment)).

I have mixed feeling about RR7 - on one hand, I'm really happy to see a stronger Next alternative, as I will NEVER use a Vercel anything, but I feel like RR team has a bit of tunnel vision going on chasing Next and SSR at the cost of keeping their base in mind. SSR is great for blogs and shopping sites, but there are still strong use cases for SPA and the best developers will choose the best tool for the job (vs. getting onboard the latest hype train). Also, I was excited about and waiting for typing support, but you get it only if you're using the Vite framework plugin, which does not apply to custom framework afaict.

[brophdawg11]

I can assure you we don't have tunnel vision on SSR - we just have a few bugs around ssr:false behaviors that we're still ironing out as we work it into Framework Mode :). We want Framework Mode to be the proper solution for most if not all apps going forward, regardless of whether they are SSR, SPA, SSG, etc.

[leonardbiofi]

On my side, I moved to Tanstack/router and everything is way more logical and simple.. I really got tired of trying to decipher the documentation of ReactRouter... WIth my SPA, I am very happy with my choices, maybe when you guys figured out this "framework" mode and solved all bugs around it, I might move back to RR

[brophdawg11]

Documentation feedback is always welcome

[zachsents]

Yeah this is a pretty insanely big blocker. I'm trying to migrate an existing SPA to get some pre-rendering on certain routes, with no plans to use SSR.

I'd guess most people using RR7 framework are in the same boat. Bummer

[einarq]

The docs should definitely make this more clear. But I think its fairly easy to opt out of by naming the routes Route.client.tsx (adding .client in the middle).

Every framework comes with opinions I guess, and RR7 Spa Mode has the opinion that every SPA should server-render the index page (whatever route you land on).

Makes sense, but makes it harder to migrate existing SPAs. But .client should be a sensible workaround.

[MikeAirey]

The documentation is downright misleading. https://reactrouter.com/upgrading/router-provider gives the very clear impression that migrating an SPA is a self-contained process, after which, SSR support can be optionally added.

Not to mention the configuration API. In what world does ssr: false mean ssr: "generate-then-discard-but-still-apply-ssr-restrictions-in-dev-mode"?
And would a little more detail on plugin presets go astray? Considering this is 1) a major new breaking change, and 2) one for which the documentation misrepresents the level of technical investment required, a few examples would be nice.

[flysky9981]

SSR set to be false only means the default export component would not be rendered in the server using rendertostring (react ssr function), but all the modules' importing side effect will make the project build failed since the whole src will be evaluated to check errors, for example, calling an client side object like window in the top level of the module. if you find this, you can wrap this module into a .client file.

[igortas]

@flysky9981 U can't expect the hype everyone should migrate to newer RR7, when u have thousands contexts in main.tsx. The whole implementation is wrong, and makes apps moving to TS router with SPA approach, and then maybe jumping to SSR mode + there is context in the routes.

[brophdawg11]

The documentation is downright misleading

The documentation is accurate - this was really a bug/oversight in how Vite bundles the server build since we do not render anything below the root but Vite still lifted module-level accesses to the module-scope of the server build.

In what world does ssr: false mean ssr: "generate-then-discard-but-still-apply-ssr-restrictions-in-dev-mode"?

We're trying to enhance the wording around the fact that ssr refers to runtime server rendering. The only way to generate your index.html is to do an SSR pass at build time. If you don't want any build time SSR and want to manage your own index.html then library mode would be the better choice.

And would a little more detail on plugin presets go astray

Looks like this doc didn't make it over from the Remix docs with the v7 upgrade - so we'll get that moved over but you can refer to that for the time being.

[brophdawg11]

This will be fixed by #13023