So, now that we've been introduced to the form helper, let's figure out how failed validation works. So, we learned in the last episode we can submit a POST request to this endpoint. That will hit a ContextController in the store action. And of course, if you're familiar with Laravel, you already know that on the condition that validation fails, it will, by default, redirect to the previous page and populate that error back. However, it should also typically check if the request was an AJAX call, and instead return that as a 422 response. But I don't think that's happening.

return that as a 422 response. But I don't think that's happening. So let's come on back, create a new contact, pull up the network tab, and let's see what happens here. Create a contact. We know that it runs the validation, and it fails, but notice we actually get a 302 redirect rather than a 422, which is, what is that, an unprocessable entity? And that's what you would normally return when processing a form made through an AJAX call. And then basically what you do in your JavaScript or your view component is you would catch

call. And then basically what you do in your JavaScript or your view component is you would catch any kind of errors and then manually populate your errors property, which you would then render up here. But notice with the form helper, you don't have to do any of that. It's automatically added to form.errors. And we can see that, let's see, inertia layout. Here's the create action, and here is the errors object. So let's figure out how that's being populated. It's probably going to be in the handleInertiaRequests middleware that we add, and if we scroll on

So let's figure out how that's being populated. It's probably going to be in the handleInertiaRequests middleware that we add, and if we scroll on down to share, let's see, we have the auth, flash, hmm, maybe on the parent? There it is, errors. Okay. So let's see. ResolveValidationErrors. Okay, this is probably what we want. Let's try to parse it. So if there are no errors in the session, then we just return an empty object.

Let's try to parse it. So if there are no errors in the session, then we just return an empty object. Otherwise, we fetch the error pack, we map over each one, and then, let's see, grab the messages and return the first item. Yeah, usually for any error messages, it will be within an array, because any key could have multiple validation error messages. So I think this just flattens it. And then, using that new Collection here, it looks like there's some way to set a Inertia error bag. Maybe this is something like setting a named error bag, just in case you have some kind

error bag. Maybe this is something like setting a named error bag, just in case you have some kind of, hmm, like an issue where two different forms have the same name, you might be able to use a named error bag so that they don't overlap, I think, I'm not sure. Otherwise, it just converts them to an array, and that gets shared. Okay, so remember, this is going to run for every single request. So if I say, hi there, and we give this a refresh, of course, it's going to run, no matter what. So every time we request a new page, Inertia will figure out what the error bag should be.

So every time we request a new page, Inertia will figure out what the error bag should be. All right, great, I think I understand it. And really, it's pretty similar to traditional form handling. Also notice, if we go back to that create view, scroll on up, we don't have to deal with that situation like in a Blade view, where you have to say, all right, give me the old lastName, because the page is refreshed. So you have to flash the old data to the session, and then retrieve it the next time the page loads. Obviously, because this is an SPA, you don't have to do that.