00:00 To start, let's get rid of this comment right here. We're basically saying TypeScript, I know you're trying to let me know how terrible my life is, but I'm going to shut you up. No, we don't want to do that. TypeScript is only there to be helpful. What it's saying is, this update accepts data for the title and content. The title and content could be a couple of

00:19 different values that are not allowed for what we've configured our database to be. It's saying the type that we're passing is a form data entry value or null. That's not going to be assignable to our string value that we need to assign it to. That's coming from this formdata.get. Now, let's dive into that a little bit.

00:38 If we look at formdata.get, it returns a form data entry value. If we dive into that, this is all like LibDOM stuff. You look at here, we're inside of TypeScript Lib, LibDOM.ts. This is all just the web platform that we're working with, which is really nice. We're not working

00:57 with some remix specific thing. When you have a form data and you try to get a value out of it, it can be either a file or a string or null. Those are your options with form data. The file is useful, of course, for file upload and stuff like that. We'll talk about that at a future time. But for our case,

01:15 we only really care about this being a string. In fact, if it's anything else, then we know we're in trouble. Maybe the form was submitted improperly or they are using postman or curl or something, and they're trying to hit it programmatically, and they're doing it wrong. For those users, I don't really care too much about their experience. But if we made a mistake,

01:35 then I do care about that experience because we want to give the user the best experience possible, even if we made a typo or something like that. We're simply going to say, if the type of title is not equal to a string, then we'll throw a new error that says title must be a string. Now, we don't want to just throw an error though,

01:55 because that will give us a 500 response, which yeah, probably is not the problem. What really is the problem is the form was submitted incorrectly. So we need a 400 response because that indicates, hey, don't try the same thing again, it's not going to work. That's the definition of insanity. So instead of throwing an error,

02:14 we're going to throw a new response, and we'll say the status is 400. Then we'll do the same thing for our content. So the type of content is not equal to a string, and we'll throw a response for that one as well. And then to make things even better, we can actually do the same thing

02:34 with our invariant response. So here we have just the imperative way to accomplish this, and it is accomplishing the task, but I like fewer lines of code and declarative code. So we're going to say invariant response, and we're going to pass type of title is equal to string. So if that's the case, then things are good.

02:53 Otherwise, we'll say title must be a string. And the default behavior for invariant response is to have a status of 400. That's a pretty common status code for this type of an experience. And so that's why that's the default, so we can get rid of that.

03:12 And then we can do the same thing for the content and get rid of this, that's functionally equivalent. And TypeScript understands that too, so it's happy. It knows that there's no possible way for the code to get to this point and have it not be a string. So it definitely will be a string by this point.

03:31 So TypeScript's happy, we're happy, our users are going to be happy. Everybody's just really happy. So let's just test this out really quick. If we had some sort of typo right here, then we come over to our app and we submit this, we're going to get a bad request. That's not a really great error page, and we're going to improve that error page later,

03:51 and we can have inline errors as well that we'll deal with in the future. But at least we're not allowing bad code to continue through and wreak all sorts of havoc on our action. So we're listening to TypeScript and helping it help us,

04:09 and we're doing a little bit of validation as well. This is a different type of validation because this is actually validating that we are doing things properly. In the future, we'll add validation that the user is doing things properly as well. So that is handling the form data types.