In this video, let's take a look at the difference between useFetch, $fetch, and useAsyncData. You've already seen how useFetch is useful for making a request, a fetch request to some URL. That's not all that's happening with useFetch, however. What do I mean?
Well, if I go and open up the source code for my Pokemon's page, and then I search for Bulbasaur, you'll notice that in the HTML, I've got Bulbasaur listed there. So my data is actually injected into the HTML and rendered on the server side. Nuxt uses what's known as universal rendering, meaning we have this server side rendering, but on the client, we also have the view app hydrated so that this also renders on the client side. And in fact, when we switch pages in our application, we never go back to the server side render, we just get it rendered here on the client side between navigation items.
If I were to refresh the about page completely though, this is also indeed rendered on the server side. Notice how the about heading here does actually show up in the H1. Okay, so if I go to Pokemon here, we can already very plainly see that the data is being fetched. on the server side.
Otherwise, this wouldn't have Bulbasaur in it. So since things run both on the server side and then are hydrated again on the client side, is my request being made again on the client side? Well, if you take a look at the network tab and let me refresh the page for good measure here, you'll notice that no request to that Pokemon API endpoint is made. So what's happening under the hood is that use fetch is deduplicating the request for us.
It makes it on the server side, but then it passes the data that it got on the server on to the client. This is known as the Nuxt payload. Let's take a look at the source code once again. If I search it here for the keywords, Nuxt underscore data, you'll see the contents of that payload is just some JSON.
If I keep scrolling, you'll see it does include the data for our Pokemon. So this is how that data is fetched on the server and then passed or forwarded to the client so that we don't have to make duplicate requests. If you open up the Nuxt DevTools at the bottom of the page, come to the little three ellipses menu right down here and select this icon with the kind of ones and zeros. you'll see all of the payload that has been passed to your page.
Basically all the state that's within the Nux payload. Here we have it keyed randomly based on the URL that we gave useFetch, but here you can see all that data that exists in the payload for the Pokemon. This brings us to $fetch. What if we changed out useFetch right here to use $fetch instead?
Well, first of all, we couldn't extract the data this way. Instead, we would have to get the data directly as $fetch returns the data directly and doesn't expose other things on an object, such as error and the ability to refetch the data. So I'll just do this. And then at first glance, everything looks exactly the same.
But let me open the network tab here and then give the page a refresh. Now you can see that the Pokemon request is made on the client side. If I view the page source again and search for Bulbasaur, you'll see that the data is included in the server-side rendered HTML. So with $fetch, the request is made twice.
The second time on the client side is totally unnecessary. So this is what useFetch is good for. useFetch is really good for grabbing data that you need to render on page load. Dollar sign fetch is really great for reacting to user events, like a click on a button.
So let's just create a quick function here called handle click. And then on handle click, we'll call dollar sign fetch and we'll just refetch these Pokemon. Now I won't do anything with this refetch data because we'll be able to see the result in the network tab. But normally this would show some kind of update on your page, or maybe you're actually posting data to an API instead of fetching it, whatever the case may be.
Okay, so on click of this button, we'll give it the label click me. I want to call the handle click function. I'll refresh the page. We're back to not making the Pokemon request on the client side because we're using use fetch.
But then when I click the click me button, sure enough, we do fetch the Pokemon with dollar sign fetch. Now, one other thing that I want to make clear about use fetch and dollar sign fetch is that after initial page load, use fetch works basically the same. It makes all the requests client side. Why?
So we never have to go back to the server to get the fully rendered page again. So I've cleared out the network tab. I'll go to the about page. but then I'll go back to the Pokemon page that calls use fetch.
And then you'll see we do indeed get the Pokemon requests sent on the client side. Okay, so I think that clears up use fetch and dollar sign fetch, but what is use async data good for? Well, you can think of use async data as a more low level version of use fetch. In fact, under the hood, all use fetch really is is use async data with a callback function pass and the dollar sign fetch method used to make the request.
So these two items right here are essentially the same thing. Now, there's a little bit of caveat there. There's some other niceties that useFetch provides that doesn't quite make it to here. And we'll talk about that a little bit more later.
But ultimately, that's all useFetch is. Why would we have use async data? Well, because sometimes you don't want to make a fetch request directly using a URL. Sometimes you want to use a JavaScript SDK or JavaScript client library in order to interact with your APIs.
What do I mean by that? Well, let's take SuperBase for example. This is a super popular backend as a service. from, give it a table name, and then use the select function to select the data you want to select.
We couldn't do this with useFetch. Instead, what we could do is we could take this right here and we could call it inside of the callback function for useAsyncData. Back over in the docs, you'll see that we can get a data and error out of use super base. And ultimately what we would want to do is we would want to return that data.
Now I don't actually have the super base SDK installed. So you can just use your imagination just a little bit here to say, you know, maybe my SDK here is called my SDK or my client library. And it just returns from some API endpoint, it returns my data. And so here you would call your client library and you would return the result of that from useAsyncData.
Now, of course, this is probably gonna do something asynchronously in real life. And so you would want to await the return of that. And then the callback function that you provide to useAsyncData is typically going to be an async function. Now, when I get the result of this, just like with useFetch, I destructure data.
When I print this on the page, you'll see that it does show my data. Awesome. Other services that would typically use a JavaScript SDK to fetch data or to set data in your backend are things like the Google Firebase Cloud Store. You've also got services like GitHub that expose APIs through a JavaScript SDK or JavaScript client.
In the case of GitHub, you would probably want to use the OctoKit client and fetch repos just like this. And of course, there's tons of different APIs out there that you don't make direct REST API requests to with a URL. That is the primary way in which use async data is going to come into play. In this video, we saw how useFetch and useAsyncData deduplicate requests from server to client, and how $fetch is great for handling user interactions.
Finally, you saw how useFetch is basically a wrapper around useAsyncData to make deduplicated fetch requests in a more developer-friendly manner, and that useAsyncData is still helpful when using client-side libraries like SuperBase, Firebase, or tons of other JavaScript libraries out there.