mirror of
https://github.com/vercel/next.js.git
synced 2026-09-20 02:25:18 +08:00
Hendrik Liebau
34dbafb46d
A `'use cache'` value with an explicit `cacheLife({ expire: 0 })` is
expired the moment it is produced, so in production the `'use cache'`
wrapper regenerates it on every read rather than serving the stored
copy. The entry written to the cache handler is never served back, so
persisting it is wasted work, and for a remote handler a needless
round-trip and stored payload.
Whether to skip that write is left to each cache handler. This change
implements it in the built-in default handler; a custom handler can opt
into the same behavior. Beyond the saved write, this makes `cacheLife({
expire: 0 })` a reliable way to keep a value out of the server-side
cache handler, which covers two cases. In a conditional opt-out, a
function with an otherwise normal cache life sets `expire: 0` for a
result that is not worth persisting, for example when an upstream fetch
errored. In client-only caching, a value is `expire: 0` by design so
that it lives only in the client cache, via Cached Navigations or
Runtime Prefetches when the route opts in, and never on the server.
The skip is gated on `!process.env.__NEXT_DEV_SERVER`. In production the
value is regenerated on every read regardless, so not storing it changes
nothing that is served. Development keeps storing it, because the
default handler's minimum retention serves the previously cached value
across reloads while the entry re-warms in the background.
A new `use-cache-default-handler-expire-zero` end-to-end test enables
the default handler's debug logging (`NEXT_PRIVATE_DEBUG_CACHE`) and
asserts on its `set()` decisions. Because the debug output is only
available from the CLI, the test skips deployment.
9 lines
122 B
JavaScript
9 lines
122 B
JavaScript
/**
|
|
* @type {import('next').NextConfig}
|
|
*/
|
|
const nextConfig = {
|
|
cacheComponents: true,
|
|
}
|
|
|
|
module.exports = nextConfig
|