Sign In Sign Up

Sign In Sign Up

Let's Learn AdonisJS 6

Playing Next Lesson In

seconds

Let's Learn AdonisJS 6

Let's Learn AdonisJS 6 #6.1

Validating Form Data with VineJS

In This Lesson

We'll learn how to validate form data using AdonisJS homegrown validation library, VineJS. With VineJS we can easily ensure our request body consists of properties we need, in the types we need them, with valid values.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 4 comments

@guy-aloni
1 year ago

Great tutorial, thanks!
How can I validate dates? I get an error Uncaught Exception: Invalid value for "Chapter.startDate". It must be an instance of "luxon.DateTime", looks like date should be cast inside the validator?

1
1. Responding to guy-aloni
  @tomgobich
  1 year ago
  
  Hi Guy! Yeah, the VineJS date validation will return back a native JavaScript Date object. You can transform the value returned by the validator into a Luxon DateTime using the transform method.
  import { DateTime } from 'luxon' const validator = vine.compile( vine.object({ startDate: vine.date().transform((date) => DateTime.fromJSDate(date)) }) )
  
  Copied!
  
  1
  1. Responding to tomgobich
    
    @guy-aloni
    1 year ago
    
    Thanks Tom!
    In my case, just if someone has the same problem, I had to add also an ISO format:
    startDate: vine.date({ formats: { utc: true } }).transform((date) => DateTime.fromJSDate(date)),
    
    2
    1. Responding to guy-aloni
      
      @tomgobich
      1 year ago
      
      Anytime!! Happy to hear you got it all working!
      
      1

Transcript

- So at this point, we're grabbing our request data off of our registration form. So we have our full name, email, and password.
What we need to do next is actually create our user. So our step one is to grab our request data. Our step two is to create our user.
Our step three is to log in that user. And then our step four is to return the user back to home. So as we've previously covered,
we can create our user by doing const user equals, oh wait, user. Let's import that from our user model, dot, and there's a create method that we can call.
And we have the data that we want to actually create the user with right here. So we can plop that directly into the create call. And that will create our user with a full name,
email, and password that we send up to the store method. Just to simplify the verification step that we have actually created a user, underneath here, let's go ahead and temporarily
console log our user. And we'll call user.serialize, just so that we see the underlying user data within the console log, rather than all of the model attributes. Let's give that a save.
With our application running, let's go ahead and dive back into our browser, visit our registration page. Let's right click before we submit anything and inspect. Let's get our network tab open.
Let's go over to the gear icon and let's persist our logs. Since these are server sent actions, our log will get cleared out anytime that we're redirected away from this page. So we want to persist the logs
so that we can actually inspect what's sending out here. Okay, for our full name, let's do John. So email, we can do test@test.com. And our password can be whatever we want.
I'll just put password there. Let's click our register button. Okay, we see a fair amount of things go out. If we scroll all the way back up to the top,
we should see our post request for our register path. If we take a look at that and take a look at the request, we can see the request data that we actually send out. Furthermore, if we jump into our terminal,
we see our user's data. So we created a user with an ID of seven here. Okay, so far so good. Let's go ahead and clear our terminal back out, jump back into our registration page.
Let's clear that out once more. And let's try running through that flow again. So we have John Doe. We'll put two in here so that we can discern the data.
We have test@test.com and password. So at this point, we have actually created a user with an email of test@test.com via our register store method,
but we're not verifying the uniqueness of this email within that method via any validation step quite yet. So whenever we hit register here, we're gonna get a 500 error because the data that we've submitted
will try to insert into the user's table. But since we've used the same email that we've already registered a user with, that's going to violate our unique constraint
that we've added onto our user's email field. And that's where and why validation comes into play here. And by default, AdonisJS uses vine.js,
their own homegrown validation library to do that. So let's get validation added in for our auth register form. Again, we can see our error here within the terminal.
Let's go ahead and temporarily stop our server, clear that out, and let's do node.ace.make.validator. This is gonna create a validation folder for us within our app directory
that can house all of the different validation schemas that we create for our forms. And we can put multiple validation schemas inside of a single file here. What I've been doing is creating an individual validator
per resource that we have. So a resource would be something like a movie, a sentence, things like that. So we can keep along that same trajectory and create an auth validator
that's broad reaching for any auth-based validations that we need to do. We'll run that. Okay, cool. So now we have a file at app validators auth.ts. While we're in here,
let's go ahead and boot back up our server and hide our terminal away. We'll scroll up to that new validator file right here and enter into it. And you'll see it started us off
with a nice import for vine from vine.js. So first what we wanna do is create an export schema. So let's do export const, and we'll call this register validator
because it's the validator specifically for our registration step. Equals vine.compile. Within this compile method, we'll do vine.object
because our form's going to end up submitting an object that we'll wanna validate with. And then we wanna do a key value pair. The key is the field name and the value is the validation rules
that we want to validate that key against. So for example, for our full name here, the field name that we're submitting with our form is full name that's coming from our input.
We can specify the rules for this full name as vine. And then from here, we wanna specify the type of the input. So whether it's a number, string, array, Boolean, so on and so forth,
or a full name, it's gonna be a string. By default, the fields that we define here will be required. So if we wanted our full name to be optional, we could chain off of the string declaration
an optional declaration as well. And now with this being optional, anytime vine.js receives a value that's either null or undefined, it will strip that away from the underlying data
that we end up receiving after our validation has run. If we just wanted to strip out undefined values and keep null values, we could switch that to nullable instead.
For a full name though, optional makes more sense. Additionally, if we wanted to, we could also set a max length for the full name as well. So we could say it can't go longer than 100 characters.
There's a plethora of other string based validations that we can apply as well, like verifying that it's alpha, alphanumeric, ASCII, bail, clone, confirmed, coordinates,
a credit card number, an email, whether it ends with a specific value, we can escape it, so on and so forth. For our full name though, I think what we have here works.
Okay, next we have our email. Here we'll wanna do vine. The value type is a string. We wanna verify that it's a valid email that's been provided. And if we wanted to,
we could have vine also normalize this email. Within this normalized email, we can either run with the defaults or we can specify email normalization options as an argument here.
If we hold command and click into our normalized email and then click into that normalized email options type and then click into it once more, we can then see everything that this will actually accept as arguments.
So we have all lowercase as a Boolean, gmail lowercase, gmail remove dots, gmail remove sub address, so on and so forth. So let's close those back out.
We'll just run with the defaults for right now. And as we ran through in the beginning of this lesson, we do need to verify that this value is unique inside of our database. So to do that, we can chain off of this
a unique requirement. And this will require us to provide in a callback function that checks whether or not the value is actually unique. So for this callback function,
we're provided the DB, the value and the field information. So we'll define that as a callback function here. And all that we need to do is use the DB, which is the database query builder
to check whether or not this email value that we're provided right here is unique inside of our database, return back true if it is and false if it is not.
So we do const result equals await DB dot from. We wanna check our users table. Oh yeah, we also want this method to be a sync. There we go.
And we'll select just the ID where our email is the value that's provided into this validation call. Then we wanna return.
If we have a result, then this is not unique and we need to return back false to signal that to bind JS. Otherwise, we'll wanna return true
because we didn't get anything back. And that means that this value is unique. So we're okay to use it. And now we're not using field, but I wanna leave it there so that you all know that it's available. So I'll prefix that with an underscore
so that TypeScript's happy with it. Okay, lastly, we have our password. Here we'll want bind. This is a string value as well. And for this one, we might wanna min length and require that to be at least eight characters.
You could use regex or any of the other available rules to make the password require whatever it is that you require for your specific application.
For us, eight characters should be good enough here. Okay, cool. So we have our register validator fully defined. And if we hover over it, we'll actually see that it knows what it should accept in
and what it's going to return back to us. We'll either get a full name of type string or undefined since it's optional. We'll get an email that's a type string and a password of type string.
So now it's time to make use of it within our register controller. So before we create our user, let's const validated data equals await. Then we'll wanna import our validator.
So we call that register validator. So we'll type that out, hit tab to auto import it from our validators auth file. And then we can call validate with it. Within this validate method,
all that we need to do is provide in the data that we wanna validate with. And once it's validated, it will return us back at those types that we saw earlier into our validated data.
So if we take a look at the type here, it knows exactly what properties we can use with this validated data. Meaning we could take our validated data and now plop that directly into our users create call.
Furthermore, should our validation fail, AdonisJS will take care of that error automatically for us. We don't need to use a try catch here. It will automatically handle
and return back an appropriate error for us. And we'll even provide validation messages by default for us as well for the validations that did fail. So with that saved, with our server running, let's jump back into our browser.
Let's go into our task bar and hit enter to resubmit the page to get it back, clear out our network requests. And let's try submitting that exact same thing again.
So we'll do john do to test@test.com, which already exists inside of our database and some password. If we submit this off, we're returned right back to this form,
which is the default behavior whenever validations fail using the validator. If we take a look, you'll see that we submitted to register and it redirected us right back to register. If we take a look at the data that we submitted,
we see that data. And if we check out our terminal, we won't see an error because that error was properly handled. And now we need to learn how we can use that default error handling to show the error back to our user
so that it doesn't just redirect them directly back to this page with no feedback.

Let's Learn AdonisJS 6

113 Lessons

14h 15m

Introduction

1

Fundamentals

2

Building Views with EdgeJS

3

Database and Lucid ORM Basics

4

Lucid ORM Relationships

5

Working With Forms

6

Authentication & Middleware

7

Filtering and Paginating Queries

8

User Watchlist

9

User Profiles

10

Admin Panel

11

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.

Sign up Sign in