In this lesson, let's take a look at the key option that's available to both useFetch and useAsyncData. But first, what is my setup here for the lesson? Well, I've created a new API endpoint called randomUser. The definition of that endpoint looks like this.
js, which I've installed between lessons, and then using it to generate a random first name and last name, as well as return a random number here. that comes from a query string variable called randomNum. I've also slept for one second just so we get a little bit of a delay in the response. Okay, great.
So here we're calling useFetch with the await keyword, and we're making a request to that slash API slash random user endpoint. Then I have set lazy to true. You've seen how this kind of caches the data already in an earlier lesson. Let me demonstrate that for you again over in the browser.
Here I have the first name of Gerald. And if I go to the about page and then back to users, notice Gerald displays for just one second. That's that sleep time until the request is completed the second time. So use fetch actually works, actually caches data without this key option.
That's because use fetch uses the URL that you provide in the first argument to generate a key for you. That means on first request, when we first reload the page here, there is nothing in the cache. But when we move to about and then back to users, there was data in that cache under that key until the new response returned. random and this should really be to string.
Now if I go to about, see notice here we have Milford and Schlischt is the last name. If I go to about and then back to users, we don't get that old data for a moment because we're providing a unique key per call of of use fetch. Okay, so the key has to be the same for it to use that stale data until the new data is fetched. Well, what if I changed the URL here in some way?
So this time I'm going to provide that random num query variable. random. Okay, so this time the URL actually changes every time the page is rendered or every time this page component is run. So on first load, we do get Leland Ortiz and we get a random number.
If I go to about now and then back to users, notice we don't get the stale data at first. We only see something on the page once the new request is made. That's because our URL changes each time. So use fetch.
uses the URL that it's provided in order to generate the key. If you provide a new URL, it won't use that stale data of a different URL. But if we wanted to provide a custom key that essentially says, I don't care what the URL is, cache it under this key instead. So I'm going to cache it under the key random user.
Then even if our URL changes, we still will use the cache data. So now over in the browser, we have and if I go to the about page and then back, notice that OCEAN does exist there for a second until the new request is made. So you have complete control over how useFetch caches your data when the lazy option is equal to true. So when you're doing these non-blocking navigation items, doing a still while revalidate kind of method is really, really very easy.
So that's how the key works with useFetch. Let's now take a look at useAsyncData. Here I've replaced the useFetch with useAsyncData and then provided a callback function that just uses $fetch to make that same fetch request we were doing before. Okay, now since we do have a unique URL each time useAsyncData is called, you might expect that we don't use the stale data, as was the case with useFetch.
Well, let's give it a try in the browser. We start off with Casey. Go to the About page and back to Users. Oh, okay, we do get Casey.
We do get this stale data for just a moment until it's replaced by Annabelle. So, since this URL here isn't actually an argument of useAsyncData, and this callback function can have anything in it whatsoever, UseAsyncData does not cache things based on some URL. Instead, the default way it auto-generates a key is based on its line number and file name. So, since the actual code here hasn't changed position in this file, we do get the stale data.
It's got the same key every time. So, how do we provide a custom key? Well, we don't provide it in the options object as with useFetch. Instead, we provide it as the first argument to use async data.
So in this case, we're just providing a static key, which means it would be the same every time. And that's really no different than just letting it auto-generate. random here and doing it to string on there just because the key is expected to be a string. So now we should not get the stale data ever because we have a unique key each call of useAsyncData.
Let's try it out. We start with Rinaldo, go to the About page, and back to Users. Sure enough, Rinaldo doesn't display while Kirin is being fetched. To sum things up, we can provide the key option to use Fetch or the first argument to use AsyncData.
in order to control when stale data is displayed from the cache when we're doing non-blocking navigation. If you want even more control over caching data, then you'll need to reach for the Get Cached Data option. And we'll look at that in the next lesson.