In this lesson, let's take a look at some of the other options that are available for both use fetch and use async data. Ones that might come in handy for you, but we haven't gone over yet. So right now I am requesting the single user, the user with the ID of one from the dummy JSON API. And if you view the page source, you'll notice that we are server side rendering this data.
What if we only wanted to make this request client side and not server side render the data. Well, if we wanted to do that, even on page load, we would set the server option to false. Now when I refresh the page and view the page source, sure enough, that data is not server side rendered. And if I were to look in the console here in my network tab on a page refresh, whoops, let me make sure I am inspecting the proper page.
we do have the request being made on the client side. What other options are available to us? Well, we could also do default. What this allows us to do is provide a default value while the data is not yet ready.
In other words, right now it's not ready on the server side. So if I return an object from here with the first name of John and the last name, of Doe, this is the data we should have rendered on the server side. And then it will be overridden by the data actually fetched from the API when the request is made on the client side. Let's refresh the page.
Sure enough, you can see for just a moment, we get that smaller object, which was the default object, and then the data from the API sets in. If I view page source once again, Here you can see first name John and last name Doe was rendered on the server side. Another instance where default would come in handy is if we were to use the immediate option set to false. This tells useFetch don't fire the request immediately.
Instead, wait for us to do it intentionally with the execute function. So on my page, I'm going to add a button under the users heading here that just says Click Me. And then on click of this button, we will call the execute function. Over in the browser, notice that we do get that default data on page load.
Even after the page has fully loaded, the request is never made. It's up to us to intentionally call execute now, which I'll do when I click Click Me. Let's take a look at one more option still that is useful in this situation. But in order for us to see it more clearly, I do want to change our request to use our internal slash API slash random user endpoint.
The reason I want to do this is because if you take a look at our random user endpoint, it returns a user with a first name and a last name. You don't have to worry about the random num for this lesson. but most importantly, it sleeps for one second. In other words, we get a more delayed response.
So, let me come back over to my page here, I will refresh, and then I will inspect the network tab. This time I'll click, click me once, and that indeed works after our delay of one second. But what if I were to click our button multiple times in rapid succession without letting the first request finish before initiating a new one? Okay, interesting.
So the first request is canceled when the second request is made. We could customize this behavior with the dedupe option, which takes one of two values, either cancel, which is the default and is what we just saw, or defer. This means don't make any new requests at all until the original pending request is done. So saving that, going back over to the browser, inspecting the page one more time.
Let me clear out the network tab here so we have a clean slate, and then rapidly click the Click Me button. So that was a click of two times, but I only have one request, the very first one that was made. So that means we've pretty much covered all of the options that are shared between useFetch and useAsyncData in this course. I'll scroll right down here in the documentation.
We covered key, server, lazy, immediate, default, transform, getCachedData, pick, watch, and even dedupe here. So if you are interested in any of those and missed any of the lessons in this course, Go back and watch them now. The only one that we did not go over together was the deep option. So take a look at the documentation for more information on that.
Finally, there are some options that are unique to use fetch and aren't really relevant to use async data. They're all the ones you would probably expect. Options like method, where you can set git, post, put, or delete. Query, which we already saw to add query string variables.
Params, which is an alias for query. The body, where you can send data along with your post or put requests. Headers, where you can set things like some kind of token headers or cache headers, anything that typically goes in the header section of a HTTP request. The base URL, so that you can separate your path.
from your actual domain and protocol and all that, as well as a timeout, which allows you to automatically abort the request after a certain amount of time, and then finally the cache option, which is a way to handle some cache through the default fetch API. So there you have it. During the course, we covered pretty much all the options available to you in depth. And now you can call yourself a master of data fetching in Nuxt.