When you use sync IO in the client in a way that needs to be fixed we
currently still just provide you with the explanation for server
components. The fixes when sync IO happens in the client are not the
same as when they happen in a server component so this update adds
client specific documentation for these situations.
Namely, the key difference is that on the server you can add caching
through "use cache" and this is not available to you in the client. sync
IO in general is (going to be) allowed in client components broadly as
long as Next.js has a fallback UI to prerender. This means that "fixing"
sync IO access in the client will usually be solved by wrapping in a
Suspense boundary. The alternative is to move the sync IO out of render
or move it to the server where it can be cached.
In the **layout.js** API reference, we talk about the limitations of
layouts but don't provide alternative examples. This simplifies the
wording, and adds examples using the recommended APIs.
Also adds more general `layout.js` examples.
Part of:
https://linear.app/vercel/issue/DOC-4696/routing-section-layouts-and-templates
Follow up: Look into template.js
---------
Co-authored-by: Joseph <[email protected]>
One of the important resources for this message is `cacheLife` and
`cacheTag`, but the links were missing, and the snippet omitted imports,
which newcomers won't know how to import unless looking up.
stacked on #78575
When I changed the dynamic validation rules to be based on the existence
of a static shell I removed an important protection for apps that have
static metadata. Now that metadata is implicitly rendered within a
Suspense boundary it is always opted into allowing dynamic. For dynamic
and partially static pages this is fine because we are going to be
generating a response per request anyways. But if you have a fully
static page and then later accidentally make your metadata dynamic your
page will deopt to partially static without any warning.
This change reintroduces the heuristic where if the only dynamic thing
on the page is metadata the build errors. If there is at least one other
dynamic thing on the page then dynamic metadata is allowed.
A similar change is not necessary for viewport because that is never
rendered in a Suspense boundary and the only way to have dynamic
viewports is to opt the entire app into dynamic with a Suspense boundary
around your root layout
Dynamic is disallowed unless a Suspense boundary is above it. This now
applies to metadaata (though this shouldn't matter because it now
streams) and viewport. To allow for fully dynamic routes including
viewport you must put a Suspense boundary around your root layout.
The file tree can be improved and share the same convention:
- Use the `txt` file extension.
- One tab indented.
- Use file tree with root `.` and trailing slash for folders.
x-ref: https://tree.nathanfriend.io
Configuring `remotePatterns` can be a hassle because you have to define
each of the parts. And if you forget a part, its a wildcard meaning it
will match anything. This is usually not desirable since most remote
images don't allow query strings.
This PR adds support for using an array of `URL` objects when defining
`images.remotePatterns`.
```js
module.exports = {
images: {
remotePatterns: [
new URL('https://res.cloudinary.com/my-account/**'),
new URL('https://s3.my-account.*.amazonaws.com/**'),
],
},
}
```
Note that wildcards must be explicit and anything missing is assumed to
no longer match.
This PR adds support for `images.qualities` configuration which is an
allowlist of qualities that can be used with the quality prop on the
Image component.
- Depends on https://github.com/vercel/vercel/pull/12792
We typically add `search: ''` on `remotePatterns` to disallow the query
string, which is the most common case.
There were a few missing places in the docs so this PR fills in those
gaps.
When using dependencies in Middleware that make use of dynamic code evaluation, Next.js emits a build error because this is not supported in the Edge runtime.
In rare cases, when the code can not be reached at runtime and can't be removed by tree-shaking, users might opt in to using the `unstable_allowDynamic` config.
When combined with pnpm, the provided glob patterns as documented at https://nextjs.org/docs/messages/edge-dynamic-code-evaluation#possible-ways-to-fix-it did not match correctly because of pnpm's use of the `.pnpm` directory.
To fix the pattern matching, we need to provide the `dot` option to [picomatch](https://github.com/micromatch/picomatch), which enables dotfile matching.
_Side note: Ideally we would detect dynamic code evaluation after tree shaking, to reduce the number of cases where users need to revert to using `unstable_allowDynamic`._
fixes#51401
## Description
Unify the note format according to the [contribution
guide](https://nextjs.org/docs/community/contribution-guide#notes).
In addition, add missing bullet points to useful links.
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening
the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution
follows the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
---------
Co-authored-by: Delba de Oliveira <[email protected]>
### Why?
To customize Image Optimation, the user can use a custom loader, but
that information was out from the related lint error message.
Closes NDX-181
## Description
Follow up #72391.
I missed some error pages.
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening
the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution
follows the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
Co-authored-by: Delba de Oliveira <[email protected]>
