react-router: [Bug]: v6 BrowserRouter set basename, not match “/”

This is the expected behavior. You need to include the basename in the URL for the page itself for the Router to match anything.

I had to fix the missing redirect to basename during migration from v5 in client-only project and I’ve ended up with this solution:

index.jsx

import React from 'react';
import { render } from 'react-dom';

import './utils/ensure-basename';

render(
  <BrowserRouter basename={config.ROUTER_BASE_URL}>
    {/* ...routes */}
  </BrowserRouter>,
  document.getElementById('root')
);

utils/ensure-basename.js

import { config } from '../config';

if (!window.location.pathname.includes(config.ROUTER_BASE_URL)) {
  window.history.replaceState(
    '',
    '',
    config.ROUTER_BASE_URL + window.location.pathname
  );
}

@alkismavridis the “fallback” is the extremely thoughtful and helpful console message that tells you the problem:

<Router basename="/fe"> is not able to match the URL "/" because it does not start with the basename, so the <Router> won't render anything.```

Ok, this might be a bit mean, but I don’t care. The expected behavior here is bad. In past versions, I had an easy way to set a basename and then automatically redirect to it from the router. Now I can’t figure out how to redirect someone who comes to the page via / to go to /basename instead. In production this will be rare since this app is routed to via another one (hence the need for a /basename prefix), but in development its a PITA.

There should be some way to redirect a user who has come to / to go to /basename so the routing can work.

So any ideas how to properly redirect user to ‘/basename’ if he lands on ‘/’?

@brianespinosa showing a white screen and a console message is no fallback of any use to my usecase. I understand you do not need the feature we are requesting, and that’s totally fine. But for many of us, the ability to define our own fallback is a very useful feature and we would like to have it.

I will restate that I had to compensate the removal of this feature by manually implementing redirects. The result is neither clean nor intuitive. This was no problem with previous versions. I only had to go through that trouble after I updated. In my opinion, this is sub-optimal.

All that I ask for is an easy way to define my own fallback in case the basename does not match, as previous versions of this library were already doing. If some user is happy with the default fallback of white-screen + concole warning, then great for them. Different people have different needs. An easy way to configure that would make everyone happy.

If you basename is /fe,

<BrowserRouter basename="/fe">
  <App />
</BrowserRouter>

then, you can add a tiny script in the root HTML file:

<script>
  if (window.location.pathname === '/') {
    window.location.assign('/fe');
  }
</script>

@brianespinosa this should be configurable. react-router should provide an easy way to provide a fallback even if the basename does not match. Everybody can then configure this behaviour as they desire.

I understand that you do not wish to configure it this way, but I fall in the exact same situation like @craigmiller160. I now have to handle the situation manually, which is not very nice.

I hope react-router team takes note of this and adds an easy way to handle it.

Well Yeah this is expected behavior , but maybe its better we could point it out in docs-v6-upgrading-v5 ? To prevent anyone like me google and follow other issus up (like #7216 until this issue Anyway, best regards

I am going back to v5. Nothing about it is said in the v6 upgrade guide. It caught me by surprise. We are using Single SPA, and the whole app just got broken after this upgrade with messages: <Router basename="apps/#/lab-app"> is not able to match the URL "/" because it does not start with the basename, so the <Router> won't render anything <Router basename="apps/#/dashboard-app"> is not able to match the URL "/" because it does not start with the basename, so the <Router> won't render anything <Router basename="apps/#/settings-app"> is not able to match the URL "/" because it does not start with the basename, so the <Router> won't render anything

I have solved this problem, redirect from root file to fe with native method window.location

@craigmiller160 as someone who has to combine multiple micro-applications that use different basenames, I absolutely do not want the basename to also redirect to that name automatically. If a redirect is needed from the root, that implementation should be handled separately.

@ehpc if you need to redirect people to the basename if they land on a root, you could do this in your server, which is likely the best option, depending on your stack. There is also the <Navigate /> component.

I came here looking for a solution to this problem within react-router; some “magic” somewhere, like @brianespinosa said. However, after reading a few comments I quickly realized that this is not an issue react-router should fix, as a matter of fact I was introducing the “unexpected behavior” from my server routing configuration by resolving “/” to my react client.

Server: NodeJS + ExpressJS

Before:

// Fallbacak to land in React
app.get(['/', `/${client_dir}`, `/${client_dir}/*`], (req, res) => {
  res.sendFile(__dirname + `/public/${client_dir}/index.html`);
});

After:

// Fallbacak to land in React
app.get([`/${client_dir}`, `/${client_dir}/*`], (req, res) => {
  res.sendFile(__dirname + `/public/${client_dir}/index.html`);
});

// Fallbacak to land in React. If user lands outside react, then get redirected to it.
app.get('/', (req, res) => {
  const theURL = new URL(req.url, base_url);
  res.redirect(`/${client_dir}${theURL.search}`);
});

Good luck, and thanks for everyone’s contributions.

thanks @abraj I put it in index.tsx

if (process.env.NODE_ENV === 'development') {
  if (window.location.pathname === '/') {
    window.location.assign('/admin');
  }
}

things work fine so far!

@alkismavridis you can handle this on your own as of today. I am not a maintainer of RR and I am not the one who closed the ticket, so you can argue with me all you want.

I appreciate the maintainer’s position to not bloat the API and to not include “magic” everywhere that not everyone might need and instead giving us an API that gives us the power to implement solutions for our own use cases.