This updates the scroll position saving to occur as the scroll position changes instead of trying to do it when the navigation is changing since the `popState` event doesn't allow us to update the leaving history state once the `popState` has occurred.
The order of events that was previously attempted to save scroll position on a `popState` event (back/forward navigation)
1. history.state is already updated with state from `popState`
2. we replace state with the currently rendered page adding scroll info
3. we replace state again with the `popState` event state overriding scroll info
Using this approach the above event order is no longer in conflict since we don't attempt to populate the state with scroll position while it's leaving the state and instead do it while it is still the active state in history
This approach resembles existing solutions:
https://www.npmjs.com/package/scroll-behaviorhttps://twitter.com/ryanflorence/status/1029121580855488512
Fixes: https://github.com/vercel/next.js/issues/13990Fixes: #12530
x-ref: https://github.com/vercel/next.js/pull/14075
* avoid pulling code in the bundle for `trailingSlash` logic when it's not enabled
* avoid cloning the url an extra time if normalizing the path doesn't change it
Avoid trailing slashes on urls that look like files. The redirect for `trailingSlash: true` will now look like:
```
Redirects
┌ source: /:path*/:file.:ext/
├ destination: /:path*/:file.:ext
└ permanent: true
┌ source: /:path*/:notfile([^/.]+)
├ destination: /:path*/:notfile/
└ permanent: true
```
The default still looks like:
```
Redirects
┌ source: /:path+/
├ destination: /:path+
└ permanent: true
```
After this gets merged, I have a few optimizations planned on the normalization code that should reduce the client bundle a little and that consolidates the `trailingSlash` and `exportTrailingSlash` options
This updates `fetchNextData` to re-use the `getDataHref` function from `page-loader` which has more verbose handling to ensure the correct `/_next/data` URL is built. Re-using this logic ensures the `/_next/data` URL can still be built even when a mismatching `href` and `as` value is provided to `next/link`.
This also fixes a case in `getDataHref` where optional values that weren't provided would fail to build the data href since the check requiring the param be present while interpolating the route values hasn't been updated to allow missing params for optional values.
An additional test case has been added to the prerender suite to ensure the `/_next/data` URL is built correctly when mismatching `href` and `as` values are provided
x-ref: https://github.com/vercel/next.js/discussions/14536
x-ref: https://github.com/vercel/next.js/discussions/9081#discussioncomment-31160
Closes: https://github.com/vercel/next.js/issues/14668
Add tests and fix for when the url contains query parameters.
`router` now uses the same method for formatting url+as pair as `Link`, will be able to share code after https://github.com/vercel/next.js/pull/14633 is merged
* Avoid adding basePath when it's not needed
When using the `basePath` setting, on pages with params it will fire a router change. This will pass the url pathname in the `as` param using the `getUrl()` function. This means the `as` path will be sent through already including the `basePath`, leading to `/basePath/basePath/path` which will cause the router to throw an error.
* lint
* Add test case and ensure removal
* Make sure to re-add before changeState
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Noticed this while reviewing https://github.com/vercel/next.js/pull/14376. After having done https://github.com/vercel/next.js/pull/13699, this code didn't feel right to me:
```js
function prepareRoute(path: string) {
path = delBasePath(path || '')
// this /index rewrite is problematic, it makes pages/index.js
// and pages/index/index.js point to the same thing:
return toRoute(!path || path === '/' ? '/index' : path)
}
```
Added a nested index page to the prerender tests and found it was rendering the `/` route on navigation. This uncovered 2 more places around the dataroute where the index path was not translated correctly.
**edit:**
Just to note that there was nothing wrong with https://github.com/vercel/next.js/pull/14376, the issue was already there, I just noticed it while reading that PR
Noticed while working on https://github.com/vercel/next.js/pull/14400 that the optional catch-all handling was missing in `namedRegex`.
This whole file also seemed quite regex heavy so I took a look at the overall logic and changed a few things. It worked by regex escaping the whole route then unescape the dynamic parts. I changed it to only regex escape the static parts, this eliminates unnecessary back and forth escaping. It also makes the dynamic parts handling more readable. The whole logic is less reliant on regexes and just uses simple string manipulation to translate the route into a regex, I didn't measure anything but as an effect this should make it more performant.
This corrects the `/_next/data` path generated when using `basePath` with `getStaticProps` in a `pages/index.js` file which was previously stripping the `basePath` without checking if `/index` needed to be appended after stripping. This also adds additional checks to the `basePath` test suite to prevent regressing
x-ref: https://github.com/vercel/next.js/pull/9872#issuecomment-646841260
This updates the named regexes output in the `routes-manifest` and the associated `routeKeys` to not use any non-word characters as this breaks the named regexes e.g. `"Invalid regular expression: "^/(?<data\-provider\-id>[^/]+?)(?:/)?$"`
x-ref: https://github.com/zeit/now/pull/4355
To make `asPath` consistent with `basePath` handling this makes sure it is always stripped including on the client under the `asPath` value and from `req.url` in the `serverless-loader`. Additional tests have been added for this behavior to ensure we don't regress on this
Closes: https://github.com/vercel/next.js/issues/14037
Closes: https://github.com/vercel/next.js/issues/14039
This correctly strips the `basePath` before generating the `route-matcher` for dynamic routes and adds regression tests to ensure these work correctly with the `basePath` feature
Closes: https://github.com/vercel/next.js/issues/13966
This adds scroll restoration handling to make sure the correct scroll position is restored after navigating back/forward to a page and the rendering hasn't completed by the time the default browser scroll restoration has taken place.
An initial failing test case was added which is working with the changes in this PR, if there are any other cases that should be added let me know and I can make sure we have them to ensure we don't regress on this behavior
---
Fixes#12530
As discussed, this streamlines the handling for `basePath` to not automatically strip and add the `basePath` when provided to `next/link` or `router.push/replace` and only automatically adds the `basePath` and when it is manually provided it will cause a 404 which ensures `href` still matches to the pages directory 1-to-1.
This also adds additional test cases that we discussed to ensure this behavior is working as intended
---
Fixes#13902
So I can't *entirely* explain why, but I believe this fixes#13132. 🙈 I basically ended up looking around at other `_next` URLs (are those asset URLs?) around the project and seeing that they tended to use `delBasePath()` to remove the base path from the current page's path whenever it was used.
When testing locally with the [repo submitted with the issue](https://github.com/robertovg/next-base-path-example), I no longer experience the constant page-reloading in dev mode when adding a query string to the URL.
Was going through _document and noticed some variable shadowing going on. Added a rule for it to our eslint configuration and went through all warnings with @Timer.
Fixes https://github.com/vercel/next.js/issues/13524
To do:
- [x] fix dev mode
- [x] there's a ~route ordering or~ trailing slash issue with top level catch-all (current tests reflect that)
- [x] in this test `/get-static-paths/whatever` should fall back to `/[[...optionalName]].js` since `fallback` is `false` in its `getStaticPaths` method. ~Currently seems to 500~ must have been a glitch
- [x] add tests for `null`, `undefined` ~and `false`~ behavior as well (if decided these are valid)
- [x] ~add tests for string params as well~ this is not allowed for catch-all routes
- [x] test behavior when fallback is enabled and a top level catch-all exists
This waits for the render to be committed to DOM before we render the route change complete event (no longer sync in new React).
We have tests that ensure this resolves.
---
Closes#12938
* Generate sourcemaps for core files that pass through Babel
* Run files through Babel instead of tsc
* Get rid of wildcard helper
* Get rid of wildcard helper
* Remove unused file
* Update wildcard imports
* Add exclude
* Get rid of object-assign helper
* Use Object.assign as it gives better output
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add basePath in link component and add/remove it consistently
* Update to not use regex for delBasePath
* Expose addBasePath as router method
* Revert "Expose addBasePath as router method"
This reverts commit 40fed596195c6affabf837e42d472452768e13a3.
* Expose basePath as router field
* Apply suggestion
* Expose basePath as router field
* remove un-used vars
* Update externals
* Apply lint fix
* Update size-limit test
* Update prefetch
* Fixed pathname check in router
Remove the query portion of the URL when checking paths
* Updated change and added trial test
* Update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Remove ts-ignore where possible
And replace by typecasts
* More accurate types
* bend cliententries in a correct shape earlier on
* comment becomes unnecessary
* add webpack overload to allow for the next.js use case
* Avoid changing public interface
Co-authored-by: Joe Haddad <timer150@gmail.com>
This adds a `isFallback` property to detect if the page is being rendered in "fallback" mode or normal mode.
Accessed via the `useRouter()` hook.
---
Closes#10527
* Adjust SSG Loading Behavior
* Update expected preview behavior
* Rename two corrections
* Only use skeleton in production for now
* Fix "should SSR SPR page correctly" test
* fix tests
* fix trailing comment letter
* disable test for now
* Add initial SSG fallback handling
* Remove extra changes and update fallback handling
* Remove extra timeout for testing
* Update SSG tests in dynamic-routing suite
* Add racing to decide between rendering fallback and data
* Update size-limit test
* Update comment
* Make sure to follow correct route change order
* Make comment more verbose for racing
* Revert getStaticData to only return Promise
* Make sure to update URL on fallback
* Add retrying for data, de-dupe initial fallback request, and merge fallback replace
* Update to add preload for fallback pages data
* Add test for data preload link
* Use pre-built fallback in production mode
* Remove preload link for fallback from _document
* Update to make sure fallback is rendered correctly for serverless
* Add support for unstable_getServerProps
* Apply suggestions from review
* Add no-cache header and update types
* Revert sharing of load-components type
* Add catchall test and update routes-manifest field
* Update header check
* Update to pass query for getServerProps data requests
* Update to not cache getServerProps requests
* Rename server side props identifier
* Update to nest props for getServerProps
* Add no-cache header in serverless-loader also
* Update to throw error for mixed SSG/serverProps earlier
* Add comment explaining params chosing in serverless-loader
* Update invalidKeysMsg to return a string and inline throwing
* Inline throwing mixed SSG/serverProps error
* Update setting cache header in serverless-loader
* Add separate getServerData method in router
* Update checkIsSSG -> isDataIdentifier
* Refactor router getData back to ternary
* Apply suggestions to build/index.ts
* drop return
* De-dupe extra escape regex
* Add param test
* Allow mismatch href and as when manually provided
* Swap warning and error and throw error in production also
* Add test for mismatch error in production
* Update to only show warning in development
* added option to changeState when onlyAHashChange
* added integration tests
* segregated tests because they caused other tests to fail
Co-authored-by: JJ Kasper <jj@jjsweb.site>