Updating the router when rerendering does not update rendered routes

[seriousManual]

I'm using React Router as a...

library

Reproduction

Bug Report

reproduction

Go to:
https://stackblitz.com/edit/react-router-bug-repro?file=app%2Froot.tsx,vite.config.ts,package.json,index.html

• click "a" -> shows "unauthorized"
• click "b" -> shows "B Content"
• click "home" -> shows "Home"

all good. 👍

• click "a"
• click "set authorized"
  simulates a deferred authorization that influences how routes are displayed.
  expected: "unauthorized" changes to "A Content"
  actual: "unauthorized" stays
• navigate to "home" and back to "a":
  "A Content" is shown

This worked with 6.22 but did not anymore when we upgraded to 6.30.
Still existing after upgrade to v7

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:
    @react-router/dev: * => 7.4.0 
    @react-router/node: * => 7.4.0 
    @react-router/serve: * => 7.4.0 
    react-router: * => 7.4.0 
    vite: ^6.0.11 => 6.2.2

Used Package Manager

npm

Expected Behavior

see reproduction

Actual Behavior

see reproduction

[seriousManual]

Maybe related:
#13159

[timdorr]

I'm actually surprised this worked in any version.

The object from createBrowserRouter should be built outside of the React render cycle and only have a single instance. You should not attempt to update the router prop of RouterProvider after the initial render. There are several internal state mechanisms throughout the library that will cause problems if the browser is attempted to be re-instantiated.

[rothsandro]

@timdorr Then what's the recommended way to work with the router in tests when a component needs to be re-rendered with different props #13159 (comment)? The testing guide doesn't cover this use case and the solution below worked fine in 7.1 and below but is broken in 7.2

const TestingRoutingProvider = ({ children }) => {
  const router = createMemoryRouter([
      {
        index: true,
        element: children,
      },
    ]),
  );

  return <RouterProvider router={router} />;
};

// In our test
const { rerender } = render(
  <SomeComponent value="foo" />,
  { wrapper: TestingRoutingProvider },
);

rerender(<SomeComponent value="bar" />);

(I'm asking here because if you don't support changing the router instance, my use case is more related to this issue and the other issue may only be used to bring back HMR support).

[seriousManual]

You should not attempt to update the router prop of RouterProvider after the initial render.

Interesting, thanks for the headsup.
Is there anywhere in the documentation that implies that one is not supposed to change router props on rerender?

And this might be kind of a philosophical question:
Isn't it a breaking change anyways when people rely on a specific behaviour that changes in a minor version update?

[highfield]

My case is similar, although not involving tests.
My app router is meant to be route-configured by a web service: at startup, the browser asks for the configuration, then the data are used to build the route array.
To be honest, I always meant to keep immutable (at least formally) the router object. So, I simply destroy the previous instance and I create a brand new one. All that is done inside a useMemo, which recreates the router, yet a useRef to keep the old instance.
That seemed working fine (up to v7.0.1).
Yesterday, after the update to the latest version (v7.4.1), something has been broken.