Introduction to Next.js 13+, v2 Mutating Data

Transcript from the "Mutating Data" Lesson

[00:00:00]
>> Mutating data, I think I slightly talked about this when we did the API stuff. But I just left a little note on this because I didn't want people going to look for different ways on how to do this. Basically, mutating data right now which, let's just describe mutating data, this just means I'm changing something on the database, I'm posting, I'm deleting, I'm updating, I'm making a change to the database.

[00:00:25] I'm leaving it in a different state than before my request was made, so that's a mutation, right? You're probably only gonna do that on a client. And the way you would have to do that is basically the exact same way you do it now, there's really no difference.

[00:00:37] They're working on a RFC for mutating data. If you look at it here, they have this really crazy example of how to refresh your data, and I'll talk about that. But we're probably not gonna dive into it cause I think it's so complicated and they're just gonna have a better solution anyway, really soon.

[00:00:55] But at the end of the day, when you make a mutation to a database, either you're gonna need the refresh data. Let's say you have a list of to dos and you update one of the to dos, you're gonna want that list of to dos in your pace to update, right?

[00:01:13] What Next.js is recommending is that you just refresh the router, which will trigger the whole server component relationship. And depending on your validation strategy, we either go get the new one or not, that's what they're suggesting. So that's one approach. The other approach is, you're mutating it, but the current view you're looking at or any view doesn't really need the data.

[00:01:32] For instance, you might be having a form where someone can sign up or sign in. There's nothing waiting, there's no UI there on that page that's waiting for the result of that. So you don't have to really do a refresh because there's nothing waiting, cuz you're gonna probably go to the next page.

[00:01:48] Was it gonna go get the user anyway, so you don't have to do a refresh there. So only if you're on the same page where there's some UI that's depending on the changes that you just made. What your mutation, do you need to do a refresh using the router, which is what they recommend here.

[00:02:01] I'm only showing you for a quick second because it is very complicated. I did not want to explain all this crazy nonsense and I also, again, think, based off the information that I've heard from them and what they see on this page, this won't be here too long.

[00:02:14] They're already working on a better process, but it's worth mentioning. I don't want you to not know what that is, but, yeah, that's happening. So mostly, for the most part, use whatever you are using. If you need to refresh the page, to get the new data, just do router dot refresh, which will trigger your server components to go do what they do.

[00:02:32] They go get data, and they will get the latest data, so, that's it.
>> I'm just curious. Would it be possible to do pagination with a server component? It seems like that might be something else that we need to handle the client side to keep track of the various pages you're on.

[00:02:49]
>> Yeah, so the question was, can you do pagination with server components? Yes, you can.
>> So I think the way you would have to do that is, cuz you can refresh what page you're on, server side, I guess it really depends on how you do pagination, right?

[00:03:07] There's cursor-based. So cursor-based is like, I left off here cuz I sorted in our filter I left off here. But there's the other one where it's just like, how's the other one work? It's like you put a placeholder. You have, here's where I left off, I'm making my own index, and I'm gonna tart off from here.

[00:03:25] Because it depends on what you need to pass on the URL, are you passing some cursor on your URL, is your pagination state living up here somewhere? Because then that would make it a dynamic URL. And then a dynamic URL depending on that, you will probably have to go to the server to get that data ahead of time and things like that.

[00:03:45] So I think you can still get away with doing it server side. Because you can get the pagination data using a database query like, how many things I have left? And then you can leverage client side specifically for just the interaction of going to the next page. So I still think you can totally do it, but it will be challenging, but possible.

[00:04:07] I'm trying to think of this website. I was working with his website where I take scenarios where it looks like you can't do it with just server, and do it with just server. Cuz I do think for the most part, you can get away with a lot of stuff with just server as long as it's not specific DOM animation stuff.

[00:04:24] But when it comes to data fetching, I'm gonna say most of the time, 90% of time, that's all you need. Yeah, I think you could do that on the server side. You just gotta go a little creative. You might actually at the store you're like, what page you're on in a cookie or something like that.

[00:04:37] So then you can see it every single service I call like, what page am I on in this cookie? And that way you're just keeping track of that page. So there's definitely ways around it, but it's not easy.