So you can control caching
with help of those fetch function settings.
You can alternatively
also add some file-wide settings
in case you had multiple components in that file
that would maybe all send fetch requests.
Instead of then configuring
all those requests manually step by step,
you could set up a configuration for the entire file,
which would then be used for all the requests
sent from anywhere in that file.
And you do that with help of two special constants
you can add to your NextJS files.
The first constant is the revalidate constant.
This constant serves the same purpose
as the revalidate setting on the fetch function
I showed you a couple of seconds ago.
You can set it to a number
and that will be the number of seconds
for which data will be cached and reused
until a new request will be sent.
Now for NextJS to pick up that constant,
you also must export it,
and this must be named revalidate
because NextJS will explicitly look for this name here.
So with that added,
even if I don't set it on the fetch function,
I'll get this same behavior as before.
I got some logs here
and now if I hammer the refresh button,
which I am doing right now,
you see only one new request was sent to the backend
and then the cached data was reused
because most of those requests
were within that five-second timeframe
after fetching new data.
So that's one way of setting this up file-wide.
Now you can also set up that other setting
where you avoid caching all together file-wide
if you want to.
Because you can also export a constant called dynamic,
which is another reserved name NextJS will be looking for.
This dynamic constant takes various values.
The default is auto and doesn't have to be set.
Alternatively, you can set this to force dynamic,
which is essentially the same
as if you set the cache setting on a fetch request
to no store.
Because force dynamic tells NextJS
to always re-fetch all the data
that's needed anywhere in that file,
which is exactly the same
this cache no store setting did,
now just applied to all requests
sent from anywhere in that file.
With that setting added,
if I open that backend log again
and I hammer that refresh shortcut here,
you'll see that a bunch of new log messages
are output here on the backend
because now indeed no data is cached.
You could also set this to force static to force caching,
but this would then really never fetch any new data,
which might often not be what you want.
But force dynamic would be another way
of avoiding caching altogether.
It's not what I'll do here,
but it is definitely a setting you should be aware of.
And then, there is one last way of making sure
that the data here is not cached,
and that's a special function
you can import from next cache,
so from this cache sub-package of the next framework.
And that's the unstable no store function
though at the point of time where you are watching this,
the unstable prefix might no longer be there.
So if you don't find a unstable no store function,
try just no store.
Because indeed this is a relatively new function,
which is recommended to be used over using this dynamic,
force dynamic setting here.
So instead of using that,
NextJS recommends using that function.
But at the point of time where I'm recording this,
this function is not marked as stable
and ready for production yet, hence the prefix.
But the idea behind this function
is that you simply call it inside of the component
where you wanna make sure that data is not cached.
So you would then get the same effect
as if you set this dynamic constant to force dynamic,
but you would now get this effect
just inside of this component
but in that component for all the requests
that might be sent to any data sources.
So if you had multiple components in the same page
and you wanna cache data in some components,
but not all components,
you might not wanna set up a file-wide cache setting.
And then, you can instead use this function
to just disable caching for one specific component.
That's what unstable no store does.
And therefore here again, if I restart that backend server
and I hammer that refresh button
or refresh shortcut,
you see a bunch of logs here
because I disabled caching for this page component.
So that's another function in this case you should know.
And these are all different ways
of managing and disabling that data cache
or of controlling that data cache.
It's up to you which approach you want to use,
you saw their differences,
and therefore it really just comes down
to your exact use case.