Next.js Discord

Discord Forum

How can I skip Next's fetch cache during development?

Answered
Mudi posted this in #help-forum
Open in Discord
MudiOP
I used to be able to open my browser's dev tools and switch on "disable cache", and it'd send Cache-Control: no-cache along with requests, and Next would skip its fetch cache. This feature is no longer working in my app. I could have sworn the feature was documented, but now I can't find it in the docs. Was this featured removed? Is there some other way to skip the cache, ideally in a way I can switch on and off easily without restarting the Next dev server?

Several times a day I'm now stopping the dev server, deleting the .next directory, and starting it again. It's getting frustrating.
Answered by Ray
try adding to the page export const dynamic = "force-static"; and see if you can skip it
View full answer

75 Replies

Asian black bear
@Mudi You can do it on the individual fetch level I know: https://nextjs.org/docs/app/api-reference/functions/fetch#optionscache
probably not exactly what you are looking for though
MudiOP
Unfortunately not.
Asian black bear
The dev server used to be too slow and now it is fast but too buggy
🤷🏼‍♀️
Asian black bear
@Mudi I was just thinking, there is a decoration you can add to a route segment to opt it out of fetch caching as an escape hatch to use a library which uses fetch internally and doesn't get along. https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#opting-out-of-data-caching
The fetchCache route segment option is configured to skip cache by default.
export const fetchCache = 'only-no-store'
if that caches still it is probably a bug
MudiOP
Unless I'm misunderstanding, this is all much too heavy handed. I just want to be able to temporarily disable cache on the fly while I'm working on my (separate) BE and so its data is changing frequently.

It used to be literally as simple as opening dev tools in the browser.
Asian black bear
I mean, next.js is running its own internal JS-based cache that the browser has nothing to do with
there certainly are web apis for caching, but you have to know next is not going to use it!
MudiOP
Not true. Nextjs used to notice the Cache-Control: no-cache request header that the browser includes when "disable cache" is turned on, and it used to skip its fetch cache in response.
Asian black bear
oh you control the other service and can add that header?
MudiOP
Browser dev tools. Network tab. "disable cache". Now requests from the browser to nextjs (or any site) have Cache-Control: no-cache in their request headers.
Asian black bear
I am still seeing the original cache-control header when I disable cache in the chrome dev tools network tab
it just... doesn't locally cache it
MudiOP
Can't speak to chrome dev tools. This is firefox dev tools.
Asian black bear
right, but next.js can't see that... it is on the request
MudiOP
The request goes to nextjs
Of course it can see it
Asian black bear
no, the response goes to next
MudiOP
Yes
That's what I just said
Wait
Asian black bear
but you have big red boxes around the request headers
MudiOP
This is a request from the browser to Nextjs
Boxed is a request header
Sent to nextjs
Asian black bear
yeah but that isn't visible to client side next.js, only on the server side route handler stuff
MudiOP
Client side next.js is irrelevant
Asian black bear
hmmm, I think maybe it does more caching than you realize
MudiOP
I'm telling you skipping the fetch cache when this request header from the browser is present used to be a nextjs feature.
Asian black bear
can you see that the next app is making new fetches for the changed data, and the server is responding with stale data?
is your page static or dynamic? it only work on static page
@Asian black bear can you see that the next app is making **new** fetches for the changed data, and the server is responding with stale data?
MudiOP
I'm seeing no new request go to my BE even after restarting nextjs, until I stop it, delete .next, and start it again
@Ray is your page static or dynamic? it only work on static page
MudiOP
That sounds backwards. Why would it work on static but not dynamic.
Do you know where the docs for this feature are?
@Mudi That sounds backwards. Why would it work on static but not dynamic.
Ray
try adding to the page export const dynamic = "force-static"; and see if you can skip it
Answer
Ray
on dev
@Mudi Do you know where the docs for this feature are?
Ray
I don't think this is on the doc
MudiOP
After export const dynamic = "force-static"; it's acting as I want. Why in the world would this cache-skipping behaviour not be an option when the page is dynamic?
I need to read up on static vs dynamic here to look into whether static is a viable option for this page. I wouldn't have thought so but apparently static doesn't mean static?
@Mudi After `export const dynamic = "force-static";` it's acting as I want. Why in the world would this cache-skipping behaviour not be an option when the page is dynamic?
Ray
that only work in dev mode, in prod mode, you would need to use revalidatePath or revalidateTag to invalidate the cache
Asian black bear
yeah that is kind of confusing, shouldn't dynamic pretty much not cache ever anyways?
or only cache for the single request?
MudiOP
I don't care about this behaviour in prod mode. Caching will always be wanted.
Ray
https://www.youtube.com/watch?v=VBlSe8tvg4U&t=421s
this feature only show in this video from Lee
Asian black bear
idk, caching between dynamic invocations could even leak sensitive information, so it actually is a big deal
Ray
I don't know why it only work in static page too, you might want to ask them in discussion
on github
Asian black bear
hahaha I try not to see vercel's true colors
Ray
lol
MudiOP
@Ray thanks for showing me this feature still exists and a way that I can still use it. As I said I need to research whether force-static is something which will actually work for me in my project.
Asian black bear
in the root layout doing something like export const fetchCache = process.env.NODE_ENV !=== 'production' ? 'only-no-store' : 'auto' might be a work around
MudiOP
What do you mean? I don't want to force caching exactly. I want the built-in configurable cache behaviour, where I can set an amount of time before it'll be revalidated. But in dev mode I want the easy on-the-fly toggleable option of skipping it, which I was getting with the feature this thread is about
@Mudi What do you mean? I don't want to force caching exactly. I want the built-in configurable cache behaviour, where I can set an amount of time before it'll be revalidated. But in dev mode I want the easy on-the-fly toggleable option of skipping it, which I was getting with the feature this thread is about
Ray
by default, the cache option of the fetch is force-cache.
when you are using dyanmic function in the page, it will opt-out to dynamic and I think it change the fetch cache option to no-store
so its skipping the cache
MudiOP
But that's not what I'm seeing. In (presumably) dynamic mode (when I don't set it to force-static) it's not skipping the cache. It's caching the responses and not hitting my BE again until I kill it and delete its cache directory.
but its better to set force-cache to the fetch than export const dynamic = 'force-static' because force-static will generate a static page in build time. not sure is that what you want
MudiOP
Indeed, I do not want a static page at build time.
@Mudi Indeed, I do not want a static page at build time.
Ray
yeah try force-cache in fetch option
MudiOP
OK, I'll try that setting. Thanks.
Even though it really sounds counter to what I want 😆
Asian black bear
that the supposedly never-cached fetch results are actually being cached ever?
@Mudi Even though it really sounds counter to what I want 😆
Ray
hmm. do you want the data being cached or no?
MudiOP
Lol usually yes. I want it to follow the rules I gave it -- cache with these tags, this amount of revalidation time etc, and to be subject to manual revalidation-by-tag calls. That much all seems fine. But I want to be able to override that and skip the cache when in dev mode by sending (from my browser to the nextjs app) the cache-control: no-cache headers, which is what happens in firefox when dev tools are open with "disable cache" switched on.
I'm good from here, thanks for your help. I'll try your suggestions thoroughly, and I'll open a discussion on Github if things are still weird.
MudiOP
Setting force-cache didn't help.

But I found by accident while continuing to debug that disabling one of my middlewares solves everything. I talked about it a bit here https://github.com/vercel/next.js/discussions/54469#discussioncomment-8978846 if anyone's interested.