Experimental basePath history defects and some feedback

[dan-cooke]

Bug report

Describe the bug

Firstly, thank you to @timneutkens for #9872 .

I appreciate that we should probably not be using an experimental feature in production but unfortunately we have to use basePath despite its experimental flag. We cannot ship our app without an Apollo Client cache. And without basePath every page is treated as a hard reload of the app, breaking our cache.

We have been using basePath since its release in 9.2.1 and it has fixed almost all our problems.

However we just recently discovered quite a major issue with the browser back + forward buttons.

While I was investigating this issue, I uncovered quite a few inconsitencies with basePath and the Link component , compared to using the Router directtly.

I would imagine a lot of these issues will be resolved by #9988 but I thought I would create this thread to document some of them just incase.

And of course my primary reason is to report the issue with the browser history when using basePath.

To Reproduce

I have created a reproduction repo to assist with this bug report. So clone the repo and open the Header.js file.

I have commented this file to take you along the reproduction of 2 issues. So the code is probably the best place to start, but I will document them here as well.

Minor inconsistency
The first defect is the inconsitency between the following:

Router.push('page/1')

and

<Link href="page/1"/>

Assuming a basePath of /test/prefix the former produces the following route:

/test/prefixpage/1

It seems to leave out the preceding slash

Wheras the latter performs the route (with a hard reload of the page)

Issue with Browser back/forward
To re-iterate our main problem here:

1. Assume a basePath of /test/prefix
2. Start at /
3. Router.push('/page/[id]', '/page/1', { shallow: true }) This is seemingly the only way to prevent a page refresh when routing with basePath. And this is form we use throughout our app.
4. You find yourself on /test/prefix/page/1 as expected.
5. Press the browser back button
6. You find yourself on /test/prefix as expected
7. Press the forward button
8. You get Error: The provided as value (/test/prefix/page/1) is incompatible with the href value (/page/[id]).

This is very strange to me, it seems that despite our Router.push call excluding the basePath - the entry in the history must have been set to include the `basePath.

Expected behavior

I would expect when hitting the browser forward button that next executes:

Router.push('/page/[id]', '/page/1', { shallow: true })

ie. it performs the same push call that was originally used.

System information

• OS: macOs
• Browser: Chrome + Firefox
• Version of Next.js:

[petvas]

We have a similar issue with Dynamic Routes, when using basePath and try to navigate with the back and forward button on the browser.

Scenario 1 Works! :

• Use <Link href="/basket" as="/basket" passHref>... to navigate to the page
• Navigate away from the page with any link
• press back button
• go back to the page without any problem

Scenario 2: Fails! :

• use <Link href={`/category/[id]`} as={`/category/${category.id}`} passHref> ... to navigate to the page
• Navigate away from the page with any link
• press back button
• Got an error message:

Uncaught (in promise) Error: The provided `as` value (/nextshop/category/19) is incompatible with the `href` value (/category/[id]). Read more: https://err.sh/zeit/next.js/incompatible-href-as

[petvas]

Another issue ( I think it is the same issue):

• SSR is not including basePath into the generated a tag.
• Hovering the a tag shows the url without the basePath at the button of the browser.

[timneutkens]

Linking #9988

basePath is experimental and not rolled out anywhere, I just did a first iteration to figure out the semantics of it. We're currently focusing on releasing getStaticProps first before reiterating on basePath

Feel free to reach out to enterprise@zeit.co and we can see if it's possible to help you out on a shorter time-frame.

[Timer]

This behavior should be fixed as of 9.3.5!

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.