To await or to not await useFetch? That is the question, right? Well, at least it's a question I hear very often. So what is the answer?
Well, that depends on what you're going for and it might vary depending on the different needs of different pages of your app. So let me show you the difference between the two and then you decide which you wanna use. Okay, so first let's note here that if we call await on useFetch, then if we view the page source, it does server render our data, right? Here is Bulbasaur printed in DLI.
If I take the await off right here, and let's give the page source a refresh, it still server renders the data. So whether you use await or you don't use await, don't worry, your data will still be server side rendered. That's not an issue. Okay.
So where does the difference come in? Well, let's add Await back in here, and then go back to my browser. And on the About page, I'm going to give it a hard refresh. If I click on Pokemon Now, it was a little bit hard to see, but you'll notice it hesitated for just a moment.
It got stuck on the About page. Why? Well, Await creates a blocking navigation. That means it's not going to show the page component where you're awaiting the data until all the data has been fetched.
Instead, it's gonna stay on the previous page. Let's slow down the request just a little bit so you can see that better. Inside of my hello API endpoint here, which I am getting the Pokemon from now, let's just sleep for two seconds so that that... pause is more defined and more apparent.
So I'm going to go back to about now, refresh the page, and then go to Pokemon again. Yeah, now it's very apparent that there is a wait, a stall there, and we don't get the Pokemon page at all until the two seconds are up. Okay, so what if we were to remove the await keyword? What's going to happen then?
Well, back over in the browser, I'm gonna hit About, refresh my page, and then hit Pokemon. Okay, interesting. So I get the Pokemon page, but the actual data doesn't come in until two seconds later. So this is a non-blocking navigation.
Non-blocking navigations happen when you move from one page in your app to another page. Notice if I do refresh the Pokemon page here, it does still take the two seconds to load. So we don't have the Pokemon coming in after the load of the page. Once again, it's still server side rendered without a wait.
The non-blocking just happens when you're navigating between different pages. Let me show you one more thing that's going on here though. If I go to about now and then back to Pokemon, it seems like we get the request data immediately. But we actually don't.
These are the Pokemon, at least for the first two seconds, these are the Pokemon that were fetched on the previous request that we made when we reached this page. Then they were replaced after the request, the current request was finished. You can't tell because the results of both requests were exactly the same. There are actually other ways of achieving this exact same result.
If I go back over to my code, put a weight back in, and then provide a second argument to use fetch, which is an options object. Okay, and one of the options that we have available to us is called lazy. I'll set this to true, go back over to the browser, head to the about page, refresh, and then head back to Pokemon. Notice that it works exactly the same as leaving off the await.
This is my preferred method. I prefer to just always put await on there and be more explicit with the lazy option about what I'm trying to achieve, but whichever approach you take to do this non-blocking navigation is totally up to you. One final way you can achieve non-blocking navigation is by removing the lazy option here, and then calling use lazyFetch. Notice we have kept the wait.
Back in the browser, I'll go to about again, refresh the page, and back to Pokemon. It works. exactly the same. So there are basically three different ways to achieve non-blocking requests.
They all do the exact same thing. The first is not using await and then doing use fetch. The second is calling use lazy fetch while still awaiting. And then the third is providing the lazy option, setting it to true on use fetch.