Previously, we weren't recording most (all?) of the Next.js measurements like `Next.js-hydration` in Concurrent Mode. This was mainly because the new API doesn't accept a callback.
Instead of special casing this, I've refactored it so that the measurements are just recorded when Root first flushes (via `useLayoutEffect`), which should be more or less the same timing for the old API.
Concurrent Mode is a little trickier for two reasons:
1. Flushes might be (slightly) delayed due to time-slicing and prioritization
2. Selective hydration might skew measurements in cases where full hydration is aborted
I don't have a good answer for those yet, so they'll need to be addressed when the time comes.
# Route Announcements
## Summary
This PR improves the accessibility of NextJS's client-side navigation by announcing route changes to screen readers.
## Context
When a user who is sighted clicks on a link, they can see the content change. It's an affirmation that what the user intended to do by clicking a link actually worked! Users navigating the page via a screen-reader will not get this feedback on NextJS sites (This is an issue on many SPA-like architectures).
https://user-images.githubusercontent.com/4213649/103017382-63b02b00-44f8-11eb-9940-fb530d2d3018.mov
## Solution
Whenever there is a route change, the new `<RouteAnnouncer />` will look for a name to give the new page and then announce it! The name is found by first looking for an `h1`, falling back to `document.title`, and lastly to `pathname`. `<RouteAnnouncer />` is a visually hidden component placed within the `<AppContainer />`.
## Demo
https://user-images.githubusercontent.com/4213649/103017401-6ad73900-44f8-11eb-8050-b3e9a7e0c3f2.mov
## Inspiration
First and foremost, this PR was inspired by @marcysutton's studies and writing, [What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs
](https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/) as well as @madalynrose's [Accessible Routing](https://github.com/gatsbyjs/gatsby/pull/19290) PR for Gatsby.
There were also learnings gleaned from the conversations within #7681.
### Related Issues & PRs
- Resolves#7681
- Relates to #19963
This pull request adjusts our experimental scroll restoration behavior to use `sessionStorage` as opposed to `History#replaceState` to track scroll position.
In addition, **it eliminates a scroll event listener** and only captures when a `pushState` event happens (thereby leaving state that needs snapshotted).
These merely adjusts implementation detail, and is covered by existing tests:
```
test/integration/scroll-back-restoration/
```
---
Fixes#16690Fixes#17073Fixes#20486
This ensures we detect domain specific locales and redirect them client-side. Tests have been added in the `i18n` suite to ensure the domain redirect is applied correctly during a client-side navigation
Fixes: https://github.com/vercel/next.js/issues/19174
This moves the scroll reset behavior to happen synchronously with the DOM commit, instead of a few ticks after the render completes.
This is necessary for components that read scroll state on mount.
---
Fixes#6462
This removes `import type` usage from our core files since `import type` requires a higher TypeScript version than currently expected.
Fixes: https://github.com/vercel/next.js/issues/19300
This pull request completely replaces our old page loader with a brand new route loader.
Our existing comprehensive test suite means I did not need to add a bunch of tests. I did add them where behavior was added or fixed.
Summary of the changes:
- Eagerly evaluates prefetched pages in browser idle time (speeds up transitions)
- Router is **no longer frozen** indefinitely if the Build Manifest never arrives
- Router is **no longer frozen** indefinitely if a page fails to bootstrap
- New `withFuture` utility instead of ad-hoc deduping per resource
- Prefetching is now delayed until browser idle time to not impact TTI
- Browsers without `prefetch` now fall back to eager evaluation instead of using `preload`
- We're now ready to serve non-static assets **with `no-store` without breaking prefetching**
- **Application can now hydrate without fetching CSS assets—this is a huge performance win that was previously blocking hydration**
---
The minor size increase here is unfortunate, but we have to incur it for correctness.
---
Fixes#18389Fixes#18642
Next.js would try to "recover" if its CSS assets went missing (i.e. a deployment occured) **while the page was initially loading**.
This handled a rare case where we'd try to let the Next.js complete hydrating even though a deployment occured.
However, in practice, this never worked: if the `fetch()` failed, that means the original assets never downloaded themselves (because the `fetch()` should be coming from disk cache).
Instead of letting Next.js get itself into a weird state, let's just stop hydration so that the page doesn't accidentally delete its styles.
The handle-no-styles behavior is already tested in `test/integration/css/test/index.test.js`. There was never a branch for it using its cached styles, so nothing else needs updated.
---
Fixes#17930
When visiting a non-locale prefixed path (`/hello` instead of `/fr/hello`) we don't trigger locale redirects currently so if another locale is matched we need to ensure this is reset to the `defaultLocale` for rendering to prevent a mis-match on the client and the server.
This also fixes hydration errors from occurring with `asPath` for `getServerSideProps` pages due to `normalizeLocalePath` expecting only a pathname and `asPath` containing `hash` and `query values also.
Fixes: https://github.com/vercel/next.js/issues/18337
Fixes: https://github.com/vercel/next.js/issues/18510
This makes sure that we detect the correct default locale for domain specific locales since a domain can have a different default locale residing at the root and we need to check this on the client for prerendered/auto-static pages. This also makes sure we disable the built-in redirect handling when on Vercel since it's handled already.
Tests for this are tricky since we need to load the browser with a custom domain which requires editing the host file. Existing tests should ensure this doesn't break non-domain specific locale behavior though. This was also tested manually while testing https://github.com/vercel/vercel/pull/5298
x-ref: https://github.com/vercel/next.js/pull/17370
This PR adjust the Web Vitals reporting to be called *after* rendering occurs. It used to work like this, but React's render method is no longer synchronous—so we have to do it in an effect.
Existing tests should cover this code path, and IMO it's unfeasible to test that it's invoked _after_ hydration.
Also removed the `&& ST` condition which is not relevant to Web Vitals.
While working on https://github.com/vercel/next.js/pull/17755 noticed a couple of cases that needed fixing and broke them out to this PR to make that one easier to review. One fix is for `ssgCacheKey` where it wasn't having the `locale` prefix stripped correctly due to the locales no longer being populated under the server instances `renderOpts` and the second fix is for the `asPath` not being set to `/` when the `locale` is the only part in the URL e.g. `/en` became an empty string `""`
x-ref: https://github.com/vercel/next.js/pull/17370
Follow-up to https://github.com/vercel/next.js/pull/17370 this adds mapping of locales to domains and handles default locales for specific domains also allowing specifying which locales can be visited for each domain.
This PR also updates to output all statically generated pages under the locale prefix to make it easier to locate/lookup and to not redirect to the default locale prefixed path when no `accept-language` header is provided.
Follow-up PR to https://github.com/vercel/next.js/pull/17370 when the path is not prefixed with a locale and the default locale is the detected locale it doesn't redirect to locale prefixed variant. If the default locale path is visited and the default locale is visited this also redirects to the root removing the un-necessary locale in the URL.
This also exposes the `defaultLocale` on the router since the RFC mentions `Setting a defaultLocale is required in every i18n library so it'd be useful for Next.js to provide it to the application.` although doesn't explicitly spec where we want to expose it. If we want to expose it differently this can be updated.
This adds the initial changes outlined in the [i18n routing RFC](https://github.com/vercel/next.js/discussions/17078). This currently treats the locale prefix on routes similar to how the basePath is treated in that the config doesn't require any changes to your pages directory and is automatically stripped/added based on the detected locale that should be used.
Currently redirecting occurs on the `/` route if a locale is detected regardless of if an optional catch-all route would match the `/` route or not we may want to investigate whether we want to disable this redirection automatically if an `/index.js` file isn't present at root of the pages directory.
TODO:
- [x] ensure locale detection/populating works in serverless mode correctly
- [x] add tests for locale handling in different modes, fallback/getStaticProps/getServerSideProps
To be continued in fall-up PRs
- [ ] add tests for revalidate, auto-export, basePath + i18n
- [ ] add mapping of domains with locales
- [ ] investigate detecting locale against non-index routes and populating the locale in a cookie
x-ref: https://github.com/vercel/next.js/issues/17110
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`.
---
This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties.
There are two main assumptions here:
1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization.
2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported.
The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place!
That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet.
Fixes#11012Closes#16707
---
cc @Timer @timneutkens
This pull request replaces our client-side style transitions with `<style>` tags over async `<link rel=stylesheet>` tags. This should fix some edge cases users see with Chrome accidentally causing a FOUC.
This also removes the need to perform an async operation before starting the render, which should remove any perceivable navigation delay.
---
Fixes#16289
This pull request reuses existing `<link rel=stylesheet>` tags if their `href` matches instead of recreating it. This is in effort to fix an edge case where the browser will FOUC on the tag swap.
This behavior should be sufficiently covered by all the existing CSS cases, as misbehavior would result in the resulting CSS styles being incorrect.
This pull request correctly tracks render cancelation behavior. Prior to this PR, we'd have an unhandled rejection that left the app in a bad state and no routeChangeError event was fired.
---
Closes#16424Fixes#16445
This fixes an edge case where every dozen or so transitions you'll see a flash depending on what's happening on the main thread at the time.
I'm not sure it's possible to test for this case, so we'll just have to do more field testing with this.
This pull request adds a test case for the reproduction provided in #12445. This bug is specifically caused when loading the next page before navigation has actually occurred.
---
Fixes#12445
