Nuxt 3 Authentication with Laravel Sanctum
This episode is for members only

Sign up to access "Nuxt 3 Authentication with Laravel Sanctum" right now.

Get started
Already a member? Sign in to continue
Playing
17. Showing validation errors

Episodes

0%
Your progress
  • Total: 1h 1m
  • Played: 0m
  • Remaining: 1h 1m
Join or sign in to track your progress

Transcript

00:00
At the moment, we're not displaying any validation errors. Let's go ahead and fix that now. So we'll start with the login page and then we'll just be able to easily add these to any other pages.
00:09
Okay. So let's go over to our login page and think about what we need to do here. So when we go ahead and send this login request or any of the other requests we're sending, we can just wrap this in a try catch and then go ahead and get the
00:23
error back, let's go ahead and catch this error in here, and that's going to be just a type of any, and let's go ahead and console log out this error. Okay. So if we go over and pull up our console, let's just get rid of the
00:37
predefined email and password in here. And let's try and send this down. Okay. So let's go ahead and hit sign in.
00:45
And yeah, we get a fetch error in here with the status code. Now from this error, we can actually extract the data out. If we go ahead and use console.dir, we can actually dive into this. So if we just open this up, you can see that we've got this data in here, which
01:01
is an object, and we've got all of the errors that come back from our API. So what we can do with this is create our up here and errors ref just to hold any of them errors. We'll change this up with a type in just a second, but
01:15
let's get these set first of all. So if we do catch an exception in here, we kind of want to make sure the status is 422. So let's go ahead and just have a look at this object again.
01:28
And you can see in here, we've got a status code. So let's say if, and we'll take the error and grab the status code from this, if it is equal to 422, then the errors value, cause it's a ref now. We want to set to E dot data, and then we have errors directly inside of that.
01:49
Okay. Let's just dump these errors out on the page first of all, and then we'll go ahead and hook them up. Okay.
01:55
So if I hit sign in, there we go. We've got all of the errors and we can start to output them on the page. Let's just go ahead and type this first of all. So if we think about it, we have got an object with a key
02:08
and then an array of strings. So let's go ahead and create out an interface for this, just so we know the type of each thing. So let's just do this at the top here and we'll create an interface
02:18
out here called validation errors. And in here we have an array with a key, which is a string. And then into that, we have a array of strings. So again, completely optional, but it helps to type this.
02:33
So let's go ahead and type this out here with this and we should be good. Okay. So that's going to work in exactly the same way, but now it's typed and now we can just go through in our template and output these errors.
02:46
So let's just do this really basically. We'll just have a VF here and we'll just say, if errors.email, if that does exist, we'll take the errors from the email and we'll just grab the first one and we'll do the same thing for the password just down here as well and switch these two
03:03
things over, okay, great, let's go over and try this out and you already saw a flicker of it there, but now we are displaying errors, let's go ahead and add this just to one more of our pages, just to test this out and then I'll let you go ahead and add this to the other ones if you want to, okay.
03:19
So once again, somewhere in here, we're going to define out our errors, which is a ref with an object in, and again, this is going to be a validation errors type in here, again, we want to check this for the error, so we're going to go ahead and try all of this because we don't want to navigate if we do have an
03:37
exception and we want to catch that error here, which will have a type of any, and then we want to set that errors, so errors.value and we'll set that to edata and errors, but only if we have a 422 status code, so let's pull that inside of this if statement and we'll check the status code for 422, okay,
03:59
great, we just need to do exactly the same thing now in our template and we're done, okay, so in here, we'll create out an if statement, if errors name, then output errors.name and grab the first error from that stack and we'll just copy this down for each of these, so we want this to be email and we want this
04:21
one to be password, okay, that should be good enough, let's go over and try this out, so let's hit create an account, we'll get rid of the defaults in here once again, now that'll be done, let's get rid of these ones and let's try this out, there we go, great, we now have working validation.

Episode summary

In this episode, we tackle the important issue of displaying validation errors to users so they know exactly what went wrong when they try to log in or sign up. We start off by focusing on the login page and walk through how to catch validation errors returned by the API. We wrap our login request in a try/catch, explore the details of the error object, and extract the useful info we need.

Then, we store the errors in a reactive ref, making it easy to show them in our template. To keep things nicely structured (and to help with TypeScript), we define an interface for our validation errors so we always know what we’re dealing with.

Once our structure is set up, we update the template to display the first error message next to each form field. After verifying that this is working on the login page, we rinse and repeat: it’s super easy to drop this logic into another page (like the sign-up page), so you’ll see just how reusable this pattern is.

By the end of this episode, we have a robust setup for catching and showing validation messages, ready to use on any form throughout the app!

Episode discussion

No comments, yet. Be the first!