Updating Journal Entries

[00:00:00]
>> Got a nice editor here, nothing crazy. Then we also need this other section on the right that we need for AI stuff. We're gonna do that later when we talk about AI stuff. So there's still gonna be a bunch of layout changes that's gonna be working on in here.

[00:00:13]
But for now, let's try to work on the auto saving part. Which if you think about it, it's really just us updating the entry, we're just updating the content. So that means we need to make a route to update, we need to make a function to update, and then we need to make the logic that does the updating.

[00:00:31]
So let's get to work. We will go into our routes api/journal. Just following rest conventions, we'll make another folder in here underneath journal called id, so that way you can make a patch request to /api/journal / the ID of the journal which you wanna patch. So on the inside of that, it's not an api route unless we make a route.ts file.

[00:01:08]
And then we want to export. Const PATCH. So we're gonna do a PATCH and not a PUT. Honestly, it doesn't matter. We can do whatever we want with whatever function we want. The verbs don't change our logic, our behavior, it just change the expectations of the client that's issuing the request.

[00:01:32]
In this case, the expectation of a PATCH is that you did an update but you didn't override that whole thing in the database, you changed some of the properties on it. Whereas a PUT would be, replace this whole thing with this thing. That's the difference, they're both updates.

[00:01:49]
One just replaces, the other one just updates. So when I think of update, I actually think of PATCH. And when I think of PUT, I think of replace. But again, you don't have to do any of that. You can make PATCH do GET if you want you can make GET do POST.

[00:02:07]
It doesn't matter, you can do whatever you want. If you use Graph QL they only ever do POST request and they only ever do 200 status codes even on errors. It doesn't matter, so it's just up to, do you want to tap into how the web has been built since before any of us were born, then yeah, you would do this.

[00:02:28]
Okay, cool. PATCH, what are we gonna do here? Well, we need access to the params. So the first thing is, let's get the request. So we have the request here. And then a params is the next argument which is an object because it's the structure and then get params like that.

[00:02:48]
That'll give us params. And then the first thing we wanna do is, because we need to update the, we wanna update the entry we first need to know who this user is. So, here I know what I'm about to do, let me make this async await getUserByClerkID like that.

[00:03:18]
So we got our user, and then we can say updatedEntry is await. Let's bring in prisma, prisma.journalEntry., and then we're just gonna say, update. And then for update, we first need to say where, so find the thing that we wanna update. In this case, we want to do our combo index here and we want to find the userId who belongs to userId and the id that belongs to params.id.

[00:04:05]
And I know it's called id on params because that's what I called the folder, it's id. Whatever I call the folder, that's what params is gonna have on it. And this thing's just still freaking out cuz it's, you forgot to add a data thing. So we're gonna add data, and then data is what we want to update.

[00:04:24]
What is the update in which you are issuing? So in this case, I wanna update content. So that means content's gonna come in from the request object. So we good, we can grab that. So I can say, looking at this structure assuming the client's gonna set up an object with a content property on it.

[00:04:49]
And since we're writing the code, it is gonna do that. And we can just await request.json, and that's how you get the body. If you've ever used Express or anything else like that in the past you've probably done like rec.body. Next.js uses web standards. It uses the request standard.

[00:05:13]
So this request standard that's default in the web, I'll open this. This is how you would get JSON from it, and it says right here. Returns a promise that resolves the result of parsing the request body as JSON, request.json. Cool, so we got the content. We got to update it thing, should be good to go.

[00:05:43]
Let's just return NextResponse.json, put a data property on there with the updatedEntry. All righty, and then we're gonna head over to our utils, api. And we need to make a function here in which we update an entry. So let's do that. Const export const, actually I'll do this at the top.

[00:06:11]
It's more screen real estate. UpdateEntry, this is just going to, I guess we could just take the content for now, since we know that's the only thing we're updating. I guess we need to id as well nevermind. So we'll say id and then the content, like that. And then what we can do is we can just say res = await.

[00:06:49]
Fetch, we're gonna make a new request like so. That request takes in a URL, so we can say createURL, which is going to be /api/journal/, I need to interpolate the id here. So we'll change that to a template stream. There we go. And then request takes in a second arguments for our method.

[00:07:25]
Which is PATCH since we did the PATCH, and then the body, it's gonna be JSON.stringify an object that has a content property on it, cuz that's what we're expecting on the back end. If you remember, we're expecting content on the body, so I'm passing that up. Like that.

[00:07:51]
Cool. And same thing. If res.ok Then we can just say yeah, given the data, await res.json and return data.data. We building abstraction around this since we repeated ourselves twice already, but it's fine. I feel like I need more reps using the new request object anyway, so I don't mind doing it until it becomes annoying to me.

[00:08:27]
Because it's still somewhat new, so I don't mind getting those reps in. Yes.
>> How would we do air handling here?
>> Yeah, I mean, I guess it depends on what you want to do with the air, but so. Basically, the res.ok just means that it was a status code.

[00:08:46]
It was a non four or 500 status code. If that's the truth, then this is good. Anything else is bad, right? This is terrible. But what you would probably want to do is, well, so there's many different ways to handle an error, right? So one you might get a error status code, that's the case, this else will be fine.

[00:09:08]
The other cases is, you get a good status code, but for some reason, this breaks trying to get json breaks. So then, you would need to try catch in here, right? So you have to do that or you could just try catch the entire fetch call, use try catch this entire thing, and then try to handle the error that way too.

[00:09:35]
But because this function is completely isolated from the UI and the UIs can be either server or client, it's probably better just to return when you find your error, when error. It's probably better just to return something like error, true or something like that, code. Whatever your codes are, and then message for UI.

[00:10:03]
You can put a message here if you wanted to, and then that way, any UI, whether it's frontend or backend, can take that and do whatever they need to do with it. That's probably how I would do it. I mean, you can even have the backend do this too.

[00:10:15]
You can have the backend send back errors. Any other questions? Yep.
>> I don't see a header object, do we get some kind of abstraction for it? Where do we specify the content type?
>> The header option, and the request objects? There is a header option in here somewhere.

[00:10:43]
Yeah, you just do headers like this. You can pass it in. I guess you're asking, where do we put it cuz I'm not using it? Well, it's just implied that if you add a body that you're probably doing JSON so you don't have to add the headers there.

[00:10:56]
It's implied you don't have to be specific using the request object, the request object was was made in late 2020s, so or I'm sorry, early 2020. So it just knows that you're probably doing JSON whereas everything before that, didn't prioritize that. So it's making a really good assumption that that's what you want.

[00:11:14]
But if you wanna do headers, you could, you could say headers. Which actually you could use the new headers like this. Yeah, there's a header standard too. There's all types of stuff. I like it, I'm for it.