React-router: [v6] Link with absolute path doesn't respect basename

Created on 26 Mar 2020  路  26Comments  路  Source: ReactTraining/react-router

Version

6.0.0-alpha.2

Test Case

https://codesandbox.io/s/react-router-v6-basepath-1dcnm

Steps to reproduce

Set up <Routes basename="/something">, and inside its component tree use a link with absolute path <Link to="/path">path</Link>

Expected Behavior

Link respects basename specified in its parent Routes, and generates URL <a href="/something/path">

Actual Behavior

Link ignores basename, and generates absolute URL from website root <a href="/path">

Comment

This is the expected behaviour of basename as described in v5 docs - e.g. here, unless it was an intentional change in v6 - was it?

Looking at the code, I suspect the problem is these two lines of resolveLocation:
https://github.com/ReactTraining/react-router/blob/dev/packages/react-router/index.js#L766-L767

If toPathname starts with a slash (like in a codesandbox example above) - resolveLocation ignores fromPathname, and as the result -聽loses basename value that it may have contained.

Most helpful comment

Just confirming that this issue is still valid in v6.0.0-alpha.5: https://codesandbox.io/s/react-router-v6-basepath-1dcnm

All 26 comments

If this is a bug indeed, then as a possible solution idea - should basename be added to the RouteContext value, and passed to resolveLocation as the base path to use with absolute URLs?

Please let me know if I can help on this. I'll be happy to fix it.

Yes, this also happens in React Router 5.
I am using nested MemoryRouter with BrowserRouter, though I am not sure if it happens only in MemoryRouter.

It renders to wrong href, though it behaves correctly when clicked.

MemoryRouter does not support basename.

On the other hand, maybe we can strip the leading slash from basename?
Ok, I think I鈥檓 sending a PR fixing this

Would anyone be able to confirm whether this is an intentional change or a bug? I'm proactively preparing a very large project for v6 and I'm a bit stuck on this - unsure whether I should expect basename to work as it previously did, or if I'm going to need to manually prepend the basename to every Link & navigate etc.

Would anyone be able to confirm whether this is an intentional change or a bug? I'm proactively preparing a very large project for v6 and I'm a bit stuck on this - unsure whether I should expect basename to work as it previously did, or if I'm going to need to manually prepend the basename to every Link & navigate etc.

脤n order to make it work in v6 you should omit the leading slash from basename

@jeffersonlicet it doesn't work if we're routing inside nested components - it appends basepath to the current path, which results in incorrect URLs

Yeah it isn't working for me either. Here's the original sandbox with the leading slash removed from basename: https://codesandbox.io/s/react-router-v6-basepath-co3h9. <Link to="/path"> still generates <a href="/path"> instead of <a href="/base/path">

Seems like an intentional change to me, did you read latest docs about migrating, especially section about relative routes and trailing slash?

@malyzeli Yeah I've been through the migration docs. They don't mention anything about the behaviour of basename being different to previous versions. Regarding the trailing slash, the docs specifically state the behaviour is the same regardless of whether the current url has a trailing slash or not so I'm unclear what this has to do with the described issue. Would you be kind enough to elaborate?

Just to clarify with the most concise example I can conjure up:

<Routes basename="/foo/bar">
  <Route path="/baz" element={<Link to="/baz">/baz</Link>} />
</Routes>

The Route with path /baz matches /foo/bar/baz because of the basename on Routes. The Link with the exact same path as the Route ignores the basename and generates an anchor to /baz. This is different to previous versions of React Router where both the Route and the Link would be prepended with the basename.

If this is intentional then perhaps basename should be removed altogether to remove confusion.

I would add to @levymetal example above that from my understanding, the intent behind basename is to support the same application deployed under different base URLs. Taking that /for/bar example above, I may have the same app deployed as https://example.com/foo/bar (no basepath), or https://example2.com/home/foo/bar (basepath /home), or https://example3.com/deep/route/foo/bar (basepath /deep/route).

In v5 one could define appropriate basepath value for these deployment (e.g. pass it down as configuration parameter), and have the app working correctly completely oblivious to the fact that it's deployed at the root URL.

In v6 the only workable approach so far seems to be passing basepath down to all components in the app, and prefixing all relevant routes/link like <Link to={${basepath}/baz} /> - which works, but it's very noisy and looks like a step back from v5.

I'm happy to PR a fix, but I was hoping to get some confirmation from react-router team here that this is indeed a bug, and/or an thumbs up on the approach to the fix outlined in my comment above

@levymetal my fault - somehow I missed @morhekil is talking about basename, thought it's about path of nested Routes!

Configured basename only on a Router component, didn't know it was moved to Routes - is that mentioned anywhere in docs?

@malyzeli

Configured basename only on a Router component, didn't know it was moved to Routes - is that mentioned anywhere in docs?

it's been mentioned in another issue here

Bumping this since there's been two releases since and it seems to still not be addressed. Old basename would automatically prepend it to Link paths. Preferable that would stay the same IMO.

Just confirming that this issue is still valid in v6.0.0-alpha.5: https://codesandbox.io/s/react-router-v6-basepath-1dcnm

This is still a problem in the recent beta

The same issue is present with the Navigate component (using 6.0.0-beta.0):

<Routes basename={process.env.PUBLIC_URL}>
        <Route path="/" element={<Navigate to="/home" replace />} />        
        <Route path="/home/*" element={<Home />} />
</Routes>

When directly opening http://localhost:3000/my-public-url-path/home it works fine.
But when opening http://localhost:3000/my-public-url-path/ I get redirected to http://localhost:3000/home.

This issue still exists

Having the same issue.
Please review this issue, it is an important feature of the library.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
You can add the fresh label to prevent me from taking any action.

a bump to keep the stale bot away

Ran into this issue as well. Any thoughts on merging fix https://github.com/ReactTraining/react-router/pull/7462?

It would certainly be great to hear the devs' thoughts regarding this issue. basename functionality has changed from v5:

  • Was this intentional? If so, do the devs have a recommended alternative for v6?
  • Was this unintentional? If so, what do they have in mind for a fix? Do they need help from the community (or is something else already in the works)?
  • Is this on their radar at all?

Some additional examples using the latest versions:

I'm trying understand what is the reason for providing basename on Routes component while having no basename support on (Browser)Router. Definitely not saying it's wrong, just that I'm unable to see the use case it's probably intended for.

I would like to know what is the recommended solution/workaround when we need to deploy React app under non-root path on the server?

Explicitly prefixing all Link/Navigate paths in the codebase seems wrong.

what you mean with non-root paths @malyzeli? like navigating to external domains? 馃

@renatobenks They mean in a subdirectory, eg foo.com/bar instead of foo.com. In previous versions of RR it's easy to run RR out of a subdirectory; all you need to do is set the basename in one location. No other parts of the codebase need to be aware of the url structure. However, in v6, basename only works for routes but not links, requiring them to be prepended with the basename. This means every link in the application needs knowledge of the basename which results in more complexity, verbosity, and/or tighter coupling to the base.

It seems the overwhelming majority prefer the behaviour of previous versions because they're much easier to set up with subdirectories, which a lot of people are doing. Also, it doesn't make sense how basename works for routes but not links. Either it should be a configuration that works for both or it should be completely removed.

I'm only repeating what has already been discussed so apologies to all who have notifications turned on.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

misterwilliam picture misterwilliam  路  3Comments

Waquo picture Waquo  路  3Comments

ryansobol picture ryansobol  路  3Comments

hgezim picture hgezim  路  3Comments

andrewpillar picture andrewpillar  路  3Comments