archive/rsnext
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rsnext/packages/next/cache.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
875 B
JavaScript
Raw Normal View History

Update revalidate handling for app (#49062) This updates revalidate handling for app and moves some exports from `next/server` to `next/cache` x-ref: [slack thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1682535961644979?thread_ts=1682368724.384619&cid=C042LHPJ1NX) ---------
2023-05-02 17:19:02 +02:00
const cacheExports = {
unstable_cache: require('next/dist/server/web/spec-extension/unstable-cache')
.unstable_cache,
Dynamic APIs (#60645) formalizes the concept of dynamic APIs inside Next to allow for varying semantics beyond just staticGenerationBailout. ### Dynamic APIs #### `markCurrentScopeAsDynamic` useful to bail out of default caching semantics but does not imply a Request specific data source was read. critically, this semantic is ignored if you are inside a cache scope #### `trackDynamicDataAccessed` Must be called before reading any data source that is derived from Request specific data. Currently this is `cookies()`, `headers()`, and `searchParams`. This kind of data access inside a cache scope is forbidden (it always should have been, but now it will error). #### `trackDynamicFetch` This one is unideal but the complexity of patch-fetch's current implementation necessitates it for now. Essentially it will postpone if we are prerendering. Long term this should be eliminated with a refactor of patch fetch. ### Other Improvements Also removes the `staticGenerationBailout` implementation as it has been replaced with more specific logic in the places it was previously being used. One area that has also been enhanced is the proxy for app-route modules. Previously we proxied the Request every time however when we are doing non-static generation executions we generally don't want the overhead of wrapping the request. In the refactor here I also improved the runtime performance by using static proxy handlers and I believe I also fixed a few bugs related to `clone` and `url` In general there has been a bit of refactoring to clarify how we should handle various render/execution states and a reduction in implicit side effects for proper execution. Another callout to notice is that app-route modules do not attempt a static generation if they are force-dynamic regardless of the PPR setting. Previously the PPR setting would opt them into this code path which is not necessary because PPR itself does not work for routes, only pages. Closes NEXT-2099
2024-01-24 01:06:12 +01:00
revalidateTag: require('next/dist/server/web/spec-extension/revalidate')
Update cache methods for app dir (#49165) This ensures we match behavior local and deployed and also cleans up naming of the methods. ---------
2023-05-03 22:21:58 +02:00
.revalidateTag,
Dynamic APIs (#60645) formalizes the concept of dynamic APIs inside Next to allow for varying semantics beyond just staticGenerationBailout. ### Dynamic APIs #### `markCurrentScopeAsDynamic` useful to bail out of default caching semantics but does not imply a Request specific data source was read. critically, this semantic is ignored if you are inside a cache scope #### `trackDynamicDataAccessed` Must be called before reading any data source that is derived from Request specific data. Currently this is `cookies()`, `headers()`, and `searchParams`. This kind of data access inside a cache scope is forbidden (it always should have been, but now it will error). #### `trackDynamicFetch` This one is unideal but the complexity of patch-fetch's current implementation necessitates it for now. Essentially it will postpone if we are prerendering. Long term this should be eliminated with a refactor of patch fetch. ### Other Improvements Also removes the `staticGenerationBailout` implementation as it has been replaced with more specific logic in the places it was previously being used. One area that has also been enhanced is the proxy for app-route modules. Previously we proxied the Request every time however when we are doing non-static generation executions we generally don't want the overhead of wrapping the request. In the refactor here I also improved the runtime performance by using static proxy handlers and I believe I also fixed a few bugs related to `clone` and `url` In general there has been a bit of refactoring to clarify how we should handle various render/execution states and a reduction in implicit side effects for proper execution. Another callout to notice is that app-route modules do not attempt a static generation if they are force-dynamic regardless of the PPR setting. Previously the PPR setting would opt them into this code path which is not necessary because PPR itself does not work for routes, only pages. Closes NEXT-2099
2024-01-24 01:06:12 +01:00
revalidatePath: require('next/dist/server/web/spec-extension/revalidate')
Update cache methods for app dir (#49165) This ensures we match behavior local and deployed and also cleans up naming of the methods. ---------
2023-05-03 22:21:58 +02:00
.revalidatePath,
cache: add unstable_noStore API (#56930) This PR introduces a new API, `unstable_noStore`, which will allow users to declaratively opt out of caching anywhere during static generation in the same way that you can specify `cache: 'no-store'` on a fetch call in Next.js. An important caveat and difference from just calling `cookies()` to opt-out of static generation is that this won't opt you out when called from within `unstable_cache` and instead defers to the cache configuration to it. ``` import {unstable_noStore as noStore} from 'next/cache'; export default async function Component() { noStore(); const result = await db.query(...); } ```
2023-10-17 16:52:46 +02:00
unstable_noStore:
require('next/dist/server/web/spec-extension/unstable-no-store')
.unstable_noStore,
Update revalidate handling for app (#49062) This updates revalidate handling for app and moves some exports from `next/server` to `next/cache` x-ref: [slack thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1682535961644979?thread_ts=1682368724.384619&cid=C042LHPJ1NX) ---------
2023-05-02 17:19:02 +02:00
}
// https://nodejs.org/api/esm.html#commonjs-namespaces
// When importing CommonJS modules, the module.exports object is provided as the default export
module.exports = cacheExports
chore: fix a typo (#57272)
2023-10-23 19:10:35 +02:00
// make import { xxx } from 'next/cache' work
Update revalidate handling for app (#49062) This updates revalidate handling for app and moves some exports from `next/server` to `next/cache` x-ref: [slack thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1682535961644979?thread_ts=1682368724.384619&cid=C042LHPJ1NX) ---------
2023-05-02 17:19:02 +02:00
exports.unstable_cache = cacheExports.unstable_cache
Update cache methods for app dir (#49165) This ensures we match behavior local and deployed and also cleans up naming of the methods. ---------
2023-05-03 22:21:58 +02:00
exports.revalidatePath = cacheExports.revalidatePath
exports.revalidateTag = cacheExports.revalidateTag
cache: add unstable_noStore API (#56930) This PR introduces a new API, `unstable_noStore`, which will allow users to declaratively opt out of caching anywhere during static generation in the same way that you can specify `cache: 'no-store'` on a fetch call in Next.js. An important caveat and difference from just calling `cookies()` to opt-out of static generation is that this won't opt you out when called from within `unstable_cache` and instead defers to the cache configuration to it. ``` import {unstable_noStore as noStore} from 'next/cache'; export default async function Component() { noStore(); const result = await db.query(...); } ```
2023-10-17 16:52:46 +02:00
exports.unstable_noStore = cacheExports.unstable_noStore
Reference in a new issue Copy permalink