All language subtitles for 018 Setting up the Login Form_en

The main goal of this section is to go over form validation.

In the next section we'll store the form data in a database.

We'll use that data to authenticate a user into our application.

Before we get into that, I want to prepare the login form.

Validating the login form is the same process as validating the registration form.

The only difference is that there are two fields instead of seven.

This is a perfect opportunity to test what you've learned.

You already have the knowledge to validate the login form.

Try invalidating the form on your own.

Get as far as you can, use any rules you like.

Try to replicate the same behavior we had for the registration form.

Good luck.

Welcome back.

If you were able to validate the form, then congrats.

If not, that's fine as well.

Let's do it together.

Open the authentication component file.

Search for the login form.

There's a comment above it that says login form.

Inside it we'll find a form similar to the registration form.

There are two fields which are the email and password fields.

We're going to validate both fields.

We'll start with the email.

First, we'll change the input element for the email to the the field component.

This component will tell the validate to validate the input.

Whenever the value changes, we'll need to assign a unique ID to the field by adding the name attribute.

We'll set it to email.

Next, we'll add the rules.

We can add rules directly to the field component.

However, I think outsourcing the rules to an object will be beneficial for readability.

First, we'll need to change the form element and the template to the V form component.

On this component, we can bind a property called validation schema to an object called log in schema.

A schema is an object that represents the fields in the form with the rules we'd like to enforce on

them.

This object doesn't exist.

We'll need to create it in the data function.

Let's do that now.

Inside the object.

We'll add the rules for the email field.

The two rules will enforce are the required and email rules.

We can work on handling the errors.

Next, it's important to provide feedback to users who are trying to log in.

Let's go back to the template.

Below the field component will add the error message component.

The component should have the text read 600 class applied to it.

This class will change the text color to red.

We'll set the name property to email.

The value for the name property should correspond to the value passed into the name property of the

field component.

We're finished working with the email field.

Next, let's move on to the password field.

It's the same as before.

We'll change the input element to the field component to tell the validate to perform validation on

the value.

Afterward, we'll set the name property to password.

With that set, let's render the errors.

We're going to copy and paste the error message component we use for the email input.

The name property will be updated to password.

The last thing we'll do is apply some rules to the password.

Scroll down to the schema object we created for the login form.

We'll add the password field to the object.

We'll use the following rules required.

Minimum.

Maximum.

You'll notice I'm using the same rules we used in the registration form.

There's not much of a reason for us to use completely different rules.

We're not going to loop through the errors for the password because it's unnecessary to do so.

The user will already know that their password is valid.

We're finished validating the inputs.

The next step is to enforce the validation in case the user attempts to submit the form without filling

out the fields.

We can do that by listening for the submit event on the form component for the login form.

Back in the template.

We'll listen for this event or the function to run will be called log in.

The Summit event will do two things for us.

Firstly, it'll enforce the validation before running the function we have in the expression.

If the validation fails in any of the fields, it will not run the expression.

Secondly, it'll prevent the page from refreshing when the form is submitted.

We're using two form components in the authentication component.

We don't have to worry about conflicts between the two.

The form component will only validate field components passed into it.

Errors in one component will not be reflected on the other.

The log in function doesn't exist.

We'll need to define it.

Scroll down to the methods object and define it.

Inside the function we're going to log the values parameter will receive from the event.

This will help us verify that the function was executed if the validation was successful.

We'll want to write more code, but let's make sure everything is working.

Save your changes and switch to the browser.

If I were to check the console, there won't be any errors.

That's great.

We shouldn't have any thus far.

Next, let's try submitting the form with invalid values.

This will break the rules because both fields are required.

We will see the error messages appear below the inputs.

Previously we received false as an error message.

However, we took the time to write generic error messages for our rules.

The messages will work in all forms regardless of where we write the form in the application.

After verifying the errors work, let's try submitting the form with valid values.

After submitting the form, the console will output the values from the fields.

Fantastic.

We can move on to the next step, which is to render alert boxes with information about the form submission

progress.

Before we get to that, there is one change I want to make to the authentication component.

If you look at the file in the editor, it's getting quite large.

I think it would be a good idea to separate some of the logic into its own component.

This separation of logic will make things easier to manage.

Here's what we'll do.

We'll create two components one for the login form and another for the registration form inside the

components directory.

Create two files called login form view and register form view.

Then scaffold both files with the template and script blocks.

I'm using Pascal casing for both file names.

View recommends either using Pascal casing or kebab casing for this course.

We're going to stick to using Pascal casing for our file names.

The next step is to start moving the forms to their respective components, starting with the log in

component, search for the log in form in the template block of the authentication component.

We're going to cut the form component completely.

Pasted into the template block of the login form component, you may need to format it after pasting

it in.

Next, go to the register form in the authentication component file cut and paste the form component.

We're going to grab the alert element to.

We'll paste it into the register form components template block.

The templates have been transferred.

They won't work until the data and methods are present.

We'll move them next.

Inside the authentication component, we're going to copy the data function.

Since the authentication component doesn't need the data anymore, we're going to remove all the properties

except the tabs property.

Go over to the register component, we'll paste in the data function to the components configuration

object without the tabs property.

Next, we'll create the methods.

Objects.

Then we'll cut and paste the register function from the authentication component to the register component.

The Register component is ready.

The login component still needs its data and methods.

Switch to the login component file in the exported object.

Define the data function and the methods object.

The log and components data can be found inside the register component since we copied over the entire

data object over to it in the data function of the register component, search for the log in schema

object.

This is the only data property we created for the log in form.

Cut and paste it into the data function for the login component.

In the authentication component file, cut the login function, paste it into the methods object of

the login component.

One last thing before we use the components, we should assign them names to make it easier to debug

the application in the login component.

Set the name property to login form.

For the register component.

Set the name property to register form.

That'll do it.

The very last step is to register the components in the authentication component.

We're going to register them locally because the forms won't be used anywhere else.

They don't need to be.

Global components inside the authentication component at the top of the script block will import the

form components we created.

I recommend prefix ing them with the word app to prevent name collisions.

Not required but recommended.

Inside the exported object, we'll create the components object.

Register both components in the object.

By registering the components they are available in the template.

We'll want to load the forms in their respective tabs.

Scrolling up will load the log and form component under the tabs.

Afterward, we'll load the register form components.

The conditional directives will need to be added for toggling the forms.

We're going to use the V if directives instead of the V show directive.

They're going to be much more efficient on the log and form component.

We're going to add the V if directive the condition will be the following tab equals equals equals.

Log in.

We'll apply the directive on the register form component.

Next in the login and register components will remove the V show directives on the form components.

That was a lot of refactoring to do, but well worth it.

This refactor will make things easier to manage.

I know I flew right through that.

If any of the steps we took didn't make sense.

I recommend reviewing any of the previous lectures for more information.

All right, let's quickly try testing the forms in the browser.

Inspect the console for any errors.

There shouldn't be any so far.

After confirming there aren't errors in the console.

Try testing the login form with valid input.

In the console.

We will see the message logged from the login function.

This is great.

We were able to move the forms into separate components.

None of the original functionality we had before was lost.

We are not finished yet.

The last thing we'll want to add is the alerts.

The alerts inform the user about the status of their submission.

We've already created the logic for this.

We can copy a lot of the code we've already written with some modifications.

Back in, the editor opened the register form component file.

In the data function, we're going to make a copy of the IND submission show Alert, Alert Variant and

alert message properties.

Then we'll paste the data properties into the data function of the login component.

We're making copies because the data properties will mainly be the same.

However, the names don't make sense.

We're going to change the word registration with log in in each of the data property names.

I'll recap what each property is for.

The login in submission property will be used to disable the button while the form is submitting the

data.

It's to prevent excessive requests.

The login show alert property will be used to toggle the alerts visibility.

The alert variant property will change the colour of the alert.

Lastly, the alert message property will be the message inside the alert.

The message property will need to be updated.

Change it to the following.

Please wait.

We are logging you in.

We can begin adding the alert to the template.

Scroll to the top of the template block.

We'll add the alert above the form component above the form component.

Add a div tag with the classes text white text center font bold p for mv for.

Will add a V if directive to toggle the elements visibility.

The condition will be the log and show alert data property.

Next we'll bind another class attribute to the login alert variant data property.

Inside the element and the expression log in alert message.

We'll need to disable the button while the form is submitting the request.

You'll find the submit button at the bottom of the form element.

Bind the disabled attribute to the expression.

Log in in submission.

By default, this will be false.

The button will remain enabled.

We'll need to toggle the properties through the login function.

Before we submit the request.

We'll need to reset the data properties if the user is submitting the form again, we'll set the in

submission and show alert properties to true.

The alert variant data property will be set to BG Blue 500.

We'll set the message property to its initial value.

We'll cover submitting the request in the next section.

In the meantime, we'll create a dummy response to let the user know their login was a success.

Set the variant property to be green 500.

This value will change the alert box to the color green.

Lastly, we'll update the message data property to the following success.

You are now logged in.

The process for validating the login form is the same as the registration form.

This is the benefit of using the validate library.

It makes the process very streamlined.

Let's give things one last test.

I recommend refreshing the browser for a fresh start.

Try filling out the form with valid values.

We will receive a success message.

That's great.

The button is disabled since we didn't toggle the in submission property back to false.

We don't need to do that since the user has logged in successfully.

We're finished.

I know I breezed right through that.

This was meant as an exercise to review everything we did.

Both forms are properly validated.

We can move on to the next step, which is to register the user and authenticate them.

We'll cover that in the next section.