Suppose we have a routing tree like such in our notifications
service
<HashRouter>
<Switch>
<Route path='/notifications/dashboard' component={A} />
<Route path='/notifications/:id' component={A} />
...
If every path in this particular service contains notifications
, it might be tempting to simply add a basename prop to HashRouter.
<HashRouter basename='notifications'>
This does make it really convenient when we have a link to a page in the same service. Instead of
<Link to='/notifications/dashboard' />
We can do
<Link to='/dashboard' />
The fundamental flaw with basename
is its totality. There is no way to escape its effects (at least with react-router-dom
components).
Say we want to direct the user out of the notification service with a URL, there is no way to do so with Link
<Link to='/tasks/123' />
// yields <a href="/notifications/tasks/123" />
This is also a hindrance to a Redirect
<Route path="/dashboard"
render={() => hasPermissions ? <Dashboard /> : <Redirect to="/403"
/>
// redirects to "/notifications/403"
One should therefore proceed cautiously (probably never in the microservice case) with basename
. As the documenation notes:
The base URL for all locations. If your app is served from a sub-directory on your server, you’ll want to set this to the sub-directory
Alternatively, we can nest routes like so
<Route path="/notifications"
render={({match: {url} }) => (
<>
<Route path={`${url}/dashboard`} component={Dashboard}
But soon with react-router v6 nested routes will just work
<Route path="users" element={<Users />}>
<Route path="/" element={<UsersIndex />} />
<Route path=":id" element={<UserProfile />} />
Top comments (0)