mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
`fetchCache` is a more fine-grained segment level cache-control configuration that most people shouldn't have to use. Current semantics of `dynamic = "force-dynamic"` will still treat the fetch as cacheable unless explicitly overriding it in the fetch, or setting a segment level `fetchCache`. The `dynamic` cache configuration should be seen as a "top-level" configuration, while more fine-grained controls should inherit logical defaults from the top-level. Otherwise this forces people to opt-into the `fetchCache` configuration, or manually override each `fetch` call, which isn't what you'd expect when forcing a segment to be dynamic. This will default to not attempting to cache the fetch when `force-dynamic` is used. As a result, I had to update one of the `app-static` tests to use `revalidate: 0` rather than `force-dynamic`, as the revalidate behavior is slightly different in that it won't modify the revalidation time on a fetch if it's non-zero. Closes NEXT-2067
16 lines
366 B
JavaScript
16 lines
366 B
JavaScript
export const dynamic = 'force-dynamic'
|
|
export const fetchCache = 'force-cache'
|
|
|
|
export default async function Page() {
|
|
const data = await fetch(
|
|
'https://next-data-api-endpoint.vercel.app/api/random'
|
|
).then((res) => res.text())
|
|
|
|
return (
|
|
<>
|
|
<p id="page">/force-dynamic-fetch-cache/with-fetch-cache</p>
|
|
<p id="data">{data}</p>
|
|
</>
|
|
)
|
|
}
|