Introduction to Next.js 13+, v2 Data Fetching Q&A

Transcript from the "Data Fetching Q&A" Lesson

[00:00:00]
>> When we use libraries to handle requests like React Query, Is that where you'd have to use use client?
>> Yes, you have to use client for React query because React queries hooks only work on client components. So yeah, React query is not something you would ever use for a server component because you're not keeping track of state.

[00:00:23] React query seems like it's a fetching library but in reality it's a caching library, it's a caching library, it's just because if you think about it it doesn't do any fetching you have to give it the fetcher. You have to give React Query the ability to fetch. It just caches.

[00:00:37] But you're not gonna do that on the backend cuz it doesn't keep track of state. This is stateless. Even the cache that is happening from the fetch is being cached client side. It's not being cached server side. All the cache happens on the client. So yeah, you couldn't use React Query on the server because, one, it's not needed cuz you're not tracking rerenders.

[00:00:57] And to it's using hooks and state, which doesn't make sense on the server. Mike you have a question?
>> Yes. So with this API call is this caching on the client side? And every time still making the call, however, deciding whether to rerender.
>> So great question
>> The data has changed or not?

[00:01:21]
>> Yeah, that's a great question. So, the question was, is this being cached on the client side, and how does it know when to rerender, and what's causing it to rerender? So, yes, it is being cached on the client side. And the way the caching works by default, is per segment, as in the route.

[00:01:37] So, React is like for this route, for this path, which in this case is just home, slash Here's the stuff that's cached for it. Here's like the results. And here's the data. And because we didn't specify any type of like caching mechanism here, it's going to default to it.

[00:01:55] Treating this data as what's called static data as in this data is never going to change. So you are manually going to have to tell me to update this. I'm just going to keep sending back the cache until you manually tell me because you haven't given me any hints on whether or not that this is a dynamic data fetch.

[00:02:14] So you have to manually opt into that and there's a lot of ways to do that. You can create your own revalidation strategy by doing something like Let's see. So you can say cache, like this, and then, Is it revalidate? No, not that. Let me see. I think I have it in here.

[00:02:36] This is advanced one. Yeah, we go. I was right and wrong. So you can say cache. For instance, if you say cache no-store, this means this is always gonna be dynamic data, and I always want it to be up to date, so never cash this. So, anytime someone goes to this route, always hit Reddit and always give me the latest, right?

[00:02:56] Do not store this anywhere, that's what that means, right? So, it gives you the ability to control that cache. But this is why I said it gets really advanced and probably by default, it's best to always use a default until that one time where you're like, why is this giving us back stale data and then go fix that one thing versus trying to think about it ahead of time.

[00:03:16] I think you'll just over optimise everything will just be like well. Let's just give ourselves control of everything and see what happens. Yeah, by default, fetch will cache all the results, which is great for static data, but say for dynamic data, you wanna do something like that, right?

[00:03:31] And there's more options, way more options. I highly recommend checking out the next stuff in the course. For the updates of the full stack app course that we're going to be working on, we will be covering more cache strategies and how to actually do that in production and why you might do it.

[00:03:45] So, but there's a lot going on there. Okay. Any other questions on fetching data on server? Yes.
>> So I guess my question is, where does the API now fit given the fact that we can do pretty much all the stuff you'd wanna do with API within our server components?

[00:04:05]
>> Exactly, yeah, so API comes in here, client, right? This is where the API comes in. This is what we're gonna talk about. So let me ask you a question. If I went to a page, I went to this page and I loaded it up for the first time, right?

[00:04:23] This is doing a get request. It's getting data is putting on a screen, would you expect to go to a page and have that page? Post something to a server? Like that seems common? Yeah, analytics aside and all that weird stuff, but like, you didn't perform an action, so you're probably not mutating the database.

[00:04:41] When you go to a website and you're like, you didn't do anything. You just went to the website. Okay, so there. And because when you do this, is when the server components come, that kind of tells you that there really isn't a good use case for doing mutations on the server.

[00:04:55] Like you almost don't need to, you're almost only exclusively getting data from a server. I mean, if you are doing some mutations on the server, it's probably not for the. Effect of showing something on a page, but maybe like a side effect of like, I don't know, analytics or you're tracking something.

[00:05:11] But it's not because you need to show on the page, usually that's because you need to get something, right? It's not a good use case to do it there. So really mutating is only for the client, right? So if you're on the client you don't have access to async components on the client.

[00:05:27] So now you have to rely on doing mutations the old hard way, React query, SWR, use effect, the stuff that we already know. And in that case, you do need an API, cuz you have to go across the network layer because you're on the client now. So you have to go through the network, talk to an API, get some information, and then come back.

[00:05:45] So that doesn't change. So you still need an API if you need to do a mutation, which is only on the client, or if your client needs to get information. As in, someone clicked this button. Therefore now I have to get this thing. So I couldn't have made that a server component, or maybe you could have.

[00:06:03] There's probably a way you could have do it, now that I'm thinking about it. But like you can still use an API for that. React just thought of this, and they have, where are my notes? Here we go. They have this thing called use. They have a new hook, it's literally just called use.

[00:06:19] That's [LAUGH]. They got rid of the stuff after it, and it's just called use now. And the use hook allows you to basically, it kind of works like React query or SWR, whereas you can just pass it to a fetcher and it will do all the caching for you and kind of figure it out, okay?

[00:06:37] The problem with the used hook is that it's not ready. I've actually tried it. It is not ready. They say it's not ready and they recommend you don't use it. But I'm bringing it up because I think it will be ready like by February. I think it's going to be pretty close when this thing is ready or whenever they do it.

[00:06:51] I think it's going to be ready really soon. So I'm bringing that up. But the recommended approach right now is just to use whatever you've been using, SWR, React query, whatever your favorite thing is to talk to an API. Right, so that's how you would do that on the client side.