mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
Zack TannerandGitHub
3be4ec6592
When using `fetch('', { cache: 'force-cache', { next: { revalidate: 5 } })` on a page that bailed out of ISR, we were effectively ignoring both values and treating the fetch as uncacheable, for several reasons:
- When `cache` and `revalidate` are both specified, we were assuming any combination of the two values is invalid, and we'd unset both the revalidate & fetch configs. In actuality these two properties are only problematic when they convey different caching semantics. This check was modified to instead only warn & unset on conflicting values, specifically `cache: 'no-store` and `revalidate: >0` as well as `cache: 'force-cache'` and `revalidate: 0`.
- When `force-dynamic` was set, we'd opt into no-store behavior on the fetch even if the fetch had an explicit cache config, which is incorrect.
Fixes #71881
24 lines
531 B
JavaScript
24 lines
531 B
JavaScript
// we want to bail out of ISR, but still leverage fetch caching
|
|
export const dynamic = 'force-dynamic'
|
|
|
|
export default async function Page() {
|
|
const dataForceCache = await fetch(
|
|
'https://next-data-api-endpoint.vercel.app/api/random?b2',
|
|
{
|
|
cache: 'force-cache',
|
|
next: {
|
|
revalidate: 3,
|
|
},
|
|
}
|
|
).then((res) => res.text())
|
|
|
|
return (
|
|
<>
|
|
<p>/force-cache-revalidate</p>
|
|
<p id="data-force-cache">
|
|
"cache: no-cache, revalidate: 3" {dataForceCache}
|
|
</p>
|
|
</>
|
|
)
|
|
}
|