Closed tpuric closed 7 months ago
I have also verified no regression. It’s had this behaviour since conception
I have explored this a little further and have noticed that it is only impacted for Links that provide string
types of to
. This behaviour is not shown when a Route
is provided instead.
The Route
path is verified by the following test
it('should render the correct link', () => {
renderInRouter(
'my link',
{
to: route,
params: { id: '1' },
query: { foo: 'bar' },
},
'/base'
);
expect(screen.getByRole('link', { name: 'my link' })).toHaveAttribute(
'href',
'/base/my-page/1?foo=bar'
);
});
I have constructed the following test which identifies the failure case for this issue.
it('should support the `to` prop with basePath', () => {
renderInRouter(
'my link',
{
to: newPath,
},
'/base'
);
const linkElement = screen.getByRole('link', { name: 'my link' });
expect(linkElement).toHaveAttribute('href', `/base${newPath}`);
});
Expected the element to have attribute:
href="/base/my-new-path"
Received:
href="/my-new-path"
Given
basePath
is enabled.When attempting to open a link in a new tab (or window) via a
ctrl
/cmd
click or right click new tab (or window), the new location omits thebasePath
prefix.This behaviour is apparent in the
basic-routing
example.E.g. When on
http://localhost:8081/basic-routing/about
, opening theGo to home
link in a new tab (or window) will lead tohttp://localhost:8081/
.