So when we submitted our form and got our error back, what actually happened there? Well, as expected, Vine.js and AdonisJS communicate with one another.

When Vine.js receives a validation error, it's going to report that to AdonisJS. And AdonisJS is going to validate that error into an HTTP response automatically

based on the accept header value using content negotiation. Meaning, if you were to submit your request with an application JSON accept header,

you'll get back a JSON based response. If you submit it with an application NVD API plus JSON header, you'll get back a response formatted specifically

for the JSON API spec. And then if you submit a server rendered form, as we have in our last lesson, it will use the session package to submit back

a flash message summary of our errors. If none of the above is true, it will just submit back in plain text. So following this logic, our errors were submitted back to us

via the session package as flash message errors. So if we dive back into our application, hide that back away and jump back into our register page,

let's inspect exactly what we're getting. So before all of our fields, let's do double curly braces, inspect. And there's a global property called flash messages

that contains all flash messages. And it also has some properties that help us work directly with our flash messages as well. Things like has to check whether or not

flash messages has a particular value to get a particular flash message and also all so that we can get all flash messages. So let's inspect the all response

whenever we submit our form with invalid data. At present, you can see it's just an empty object because it has nothing inside of it. For our full name, we'll continue along our same path.

Our email, we'll use our test@test.com that already exists inside of our database and we'll type in some password. Actually, let's take our password underneath eight characters so that fails as well.

So we would expect our email to fail with our uniqueness check because we're submitting a non-unique email and we're also expecting our password to fail the min length requirement that we've added of eight characters.

So whenever we hit register here, we're redirected back and we can see that our flash messages contains a few things for us. We have our full name and email that we've submitted.

Password has been omitted here for security sake. And then we have our input error bag, which contains errors specifically for our HTML input fields.

Then we have generalized errors down here as well. These also contain our input errors, but our input errors is specifically just for the input errors, whereas errors is for general errors as a whole.

Within both of these errors, we see that our email has failed because the email has already been taken and the password has failed because the password field must have at least eight characters.

So what's returned back to us are the actual validation error messages that we can then display back to the user directly. So if we hide our browser back away, get rid of our inspect call

and let's start with just our email here at first. So there's a global flash messages property made available by AdonisJS via the session package.

So we can do @if flash messages and inside of our has method, all that we wanna do is specify the identifier specifically for our error.

So for this, we can reach inside of our errors object and then we can use a dot based syntax to specify that we wanna reach inside of that errors object and check specifically for the email key

inside of that object. So if our flash messages has an errors.email value, then we'll end our if and we'll want to display that error.

So we can use double curly braces, reach for our flash messages and then get that error. So errors.email. And as we just saw, this will return back as an array.

So lastly, we can join that as a comma delimited list of errors. Okay, we'll give that a save. Let's jump back into our browser and try submitting once more. So john test@test.com

because that already exists inside of our database, we wanna test our failures and we haven't quite added our error yet for our password, but we'll enter whatever in for there. Okay, let's run this and there we go.

So now we can see that our email has already been taken. Perfect, so we're getting our validation error. Since find, Adonis and edge all work together in synchrocy, we can actually use a utility to make this call

a little bit easier as well. So let's hide our browser back away and instead of doing all of this boilerplate work, we can instead use some helpers. So there's an input error helper tag.

It's going to use that input errors bag that we saw whenever we inspected our flash messages to determine whether or not we have an error available. So this is going to work similar to an if check.

So we can jump down here and end that tag. Inside of this method, we want to provide back just the input name that we want to check against, which would be our email. And then this input error,

if it determines that we have an error to display for our email, we'll inject that errors array directly inside of this tag as dollar sign messages.

So if we want to display all messages, we could loop over them or we could just join them together as a common delimited list. And so now we can use this rather than all of this

to display our error messages. Furthermore, we can just copy this, paste it down on our password, update the field name to password to match the name of the actual field that we're using or the input.

And then let's do the same thing here for our full name. So full name there. Awesome. So now we have input error handlers added in for all of our registration inputs. So if we dive back into our browser,

let's type this out once more. So johnbest@test.com and some not quite a character value for our password. Hit enter, and there we go. So now we get the email has already been taken still

for our email and the password field must have at least eight characters for our password. We can style that up a little bit as well by providing whatever we want inside of this input error.

So we could do, let's say a paragraph with class text, extra small text, red 500, and plop the value inside of there. And since all of these use that same messages,

dollar sign join, we could just give this whole thing a copy and paste that into each one of our errors. And if you're thinking ahead, you can probably already start to guess how we can compose this label, span, input,

and error all into a component. But if you're not quite there, we'll take a look at that here in a little bit. Okay, so let's jump back into our browser. Give this one more test. So johnbest@test.com

and some password, not quite eight characters. Hit enter, and there we go. So now the text is smaller and it's red. Before we move onward though, we can actually simplify our validation logic as a whole

inside of a register controller as well. So currently we're using the actual validation schema to perform our validation and providing in that data manually.

Well, since AdonisJS and Find.js work great together, Find.js is actually available directly on a request and it will be able to automatically pluck our request data out for us.

And then all that we need to do is specify the schema that we want to validate with. Kind of just inversing the flow of what we have going on here. So let's do that up here at the top. So you can do const data.

We'll ignore that red squiggly here since we've already defined data. And we can await request.validateUsing. And then all that we need to do

is provide it the validator that we want to validate with, which would be our register validator. The request will then pluck the data off of our request itself,

provide it into our validator to validate with, and then kick back that response to us with that same validated type that we saw earlier.

This means that this line here is now our step one as that's grabbing our request data and validating it. So we can get rid of this line here as a whole. And then for our createUser step,

we now have access to that same data right here. So we can just provide in data there. We no longer need to validate it again. Simplifying our logic flow here a little bit.

Let's jump back into our browser one more time just to make sure that all of this worked. We'll give it a refresh. Type in john test@test.com and some invalid password.

Run there and everything still works A-okay.