00:00 Applications need to mutate data. Users need to be able to interact with that data, and this is where building web apps can be really complicated, unless you're doing things the way we're going to do it, and it's awesome. So we're going to talk about data mutations. So in this exercise, you're going to be able to make a change to one of the notes,

00:18 and it will apply, and it'll be awesome. You'll also be able to delete notes, and that will also work. And that's a form submission that we're going to be doing. That is just a single-button form submission. So how is this going to work? Well, first of all, the way the web platform works

00:36 is you use forms to submit some data. Now, the default for a form is to have a method of get, and so what it's going to do is it will take this value, sandwich type, and it will serialize it into a query string that it will stick in the current URL. The default also is to take the current URL,

00:56 but you can customize these things, and it's a really good idea to do so for many things. Anything you don't want to have show up in the URL, for example, a login. You certainly wouldn't want the user's password to show up in the URL. That would be super bad. Their password would show up for co-workers to look at,

01:16 or friends, or whatever, and then their password would also show up in any logs where you're logging the URL. So no, you wouldn't want to use that. So what you do is you use method post, and with method post, now it doesn't show up in the URL. It's part of what's called the post body. So the browser will serialize the values of the form,

01:34 so in this case, the username and the password, and it will stick that in the request, and then the server can get access to that. You can also specify an action, and so this would be the URL that it's making the request to, and this is where the browser is going as it's making this submission.

01:52 So then on the server side, you can get access to the form data with the request, and from there, you have a regular form data object. So this is, again, MDN to IO. Head over to MDN to learn all about the form data object that you get from the request. It's pretty stellar that we're spending so much time learning

02:12 the web platform here. But there's one other thing I want to talk about before we talk about the fetch aspect of this, and that is post redirect get. So when the user types in a form and then hits submit, they're going to post to example.com wherever. The server is going to handle that, do whatever mutation it's going to do,

02:31 and then it's not going to send HTML. You should not do this. A lot of products do this, and what happens here is that this post request is going to get put into the history stack, so like your forward and backward button. That stores not only the URL you are at,

02:50 but also your scroll position as well as the method that it's at, so the get or a post. It probably stores a couple other things as well. So if you go through and you're submitting, and then you decide, oh, I need to go back, it's going to get to the entry in the history stack that

03:07 says, oh, you submitted a post to get this HTML, so I need to submit a post again to get that HTML. That's what's going on here. It says, oh, that's how you got here, so I've got to submit the post. Well, this is very problematic. If the post that you made was send my brother $1,000 or buy this really expensive plane ticket.

03:26 And so this is why you will sometimes see a little notice at the top of the page that says, don't hit the back button. It's because they did this wrong, because there's a way you can prevent this problem from happening, and that is by doing what's called post redirect get. So you make the post request, then the server does its mutation stuff, and then it sends back

03:46 a location header with a 302 status code or some other redirect status code to say, hey, I want you to go here now. So the browser says, oh, OK, I'm not even going to bother putting that post request in my history stack, and instead, I will go and get that new URL. And then the server can say, OK, so here's your HTML.

04:06 You can go look in the database, find the stuff that it needs, and then send that. So this is the way that you do it in traditional web applications, and because we care about progressive enhancement, this is the way we do it in Remix as well. But things get a little bit complicated when we add in fetch.

04:21 So if you're doing a like the post button, or delete the note, or edit the note, or whatever, when you do that, you've got to think about what happens when I change this, and we've got the note right here that has the title, and I submit that.

04:40 That title needs to get updated over there. And so once we start preventing default and not letting the browser do the full page refresh, we're no longer going to the server every single time like we're doing here. We go to the server to get the brand new data every time. So we never, with this traditional model of full page refreshes, we never had

04:58 to worry about the data on the page being stale based on what I just changed. But when we decide, hey, we actually don't like the full page refresh, and there are a couple of other things we want to use JavaScript for, so we're going to use fetch. Now we have the problem of we mutated something, and now we've got to make sure all the data on our page that's

05:17 affected by that mutation is going to be updated. Well, the cool thing is that Remix, it brands itself as a browser emulator. And so it says, hey, the browser would actually go to the server and get the updated HTML. We will go to the server and get the updated data.

05:36 And so because Remix is responsible for doing your data loading, it's also responsible for doing your mutation. So when you make a mutation, Remix will automatically reload your data for you as well, which is pretty awesome. So and of course, there are ways to opt out of that behavior. But we're going to be learning about that in this exercise.

05:56 So let's take a look at this. This is the way that it works. It actually kind of resembles the loaders, except there's a UI aspect to this as well, and that is the form. Like it's basically standard form stuff. And so here we have our method of post. I should mention that the browser supports

06:16 only get and post as these methods. If you supply anything else, it will fall back to get as the default. So you can only use method get and post for the browser. Remix, on the other hand, will support the other methods. But the problem with using those is you lose on progressive enhancement,

06:34 which we'll talk a little bit about in the exercise. So only use get and post. So here we say form method post, and it will post to this action. The action will handle it, do all the validation, whatever you want, and then you send a redirect when that request is successful. Things change a little bit if you're

06:51 doing a mutation that doesn't actually need to send to the user somewhere else. You want to keep them on the same place. But for the most part, yeah, you're going to send them right back to where they were before. So this would be like if you had a post and you wanted to favorite the post. You don't want to send them somewhere else. So you will do things a little bit differently,

07:10 and we'll get into that in a future workshop, not today. So for us today, we're only going to do the redirect because that solves a lot of the problems that the web has. You know that confirm resubmission thing? I didn't mention this, but whenever you hit the Back button, it says Confirm Resubmission.

07:27 That's because people were doing this instead of this. So that wouldn't be a problem at all if they would just do the post redirect get stuff, right? OK, I think that I've given you everything that you need to know about this exercise. So why don't you jump into the first step, and let's get going.