In this lecture, we were going to add the last piece of the puzzle to our log in form.
We need to handle the forms of mission.
It's not going to be much different than what we did before.
Therefore, I think it would be a great opportunity as an exercise.
There are three steps you will need to take.
First, disable the button.
Users shouldn't be able to submit the form until the form is valid.
Second, and tailwind classes for changing the appearance of the button if it's disabled.
Lastly, listen for the submit event on the form.
Pause the video and good luck.
Welcome back.
If you're able to submit the form, that's great, if not, that's perfectly fine.
Let's go through the solution together.
Open the log in template file.
The first step is to disable the button at the top of the form.
We've added a template variable to the form element.
We will have access to the form group object, which contains the current status of the form.
That's going to help us toggle the button at the very bottom of the form.
We will find the button bind the disabled attribute to the log and form invalid property.
The invalid property will store a Boolean value.
It'll tell us if the form is invalid, if this property is true, the disabled attribute will be added
to the button.
This behavior should stop the user from submitting the form until the form is valid.
Alternatively, you could try checking the valid property if that's what you did.
That's perfectly fine.
I'm choosing an alternative property to spice things up.
There isn't an advantage to either solution.
Next, let's add some classes to the button to help the user understand they can't submit the form tailwind
ships with varying classes for when an element is disabled.
We can add classes if the button is disabled by adding the disabled variant, followed by the name of
the class.
We are going to apply to two classes for when the button is disabled there the Opacity 50 and Biji Indigo
400 classes.
We're setting the opacity to 50 percent.
Changing the background color will prevent the hover effect from being applied.
We can move on to the final step.
We need to listen to the submit event.
Scroll to the top of the form on the form element.
We will add event binding to an event called N.G. Submit.
As a reminder, the Energy Submit Directive will limit the submit event while preventing the default
behavior of refreshing the page.
If this event is emitted, we will run a function called log in.
This function doesn't exist.
Let's define it inside the class file, open the log in component class file.
Next to find the log and function.
Inside this function, we will log the credentials object.
Lauding the credentials, object will allow us to verify the form submission was captured after logging
the object.
Let's test our form.
Initially, the button will be disabled because validation is performed when the page loads, both fields
will be invalid.
Let's try adding valid values to the fields.
Fantastic.
The button is enabled.
If we submit the form, the page shouldn't refresh, the energy submit directive will prevent the default
behavior.
Let's check if the console is logging the form data.
The credentials object stores, the email and password.
We're finished working on the login form, this entire section has been dedicated to template forms.
As you can see, they're much simpler to work with, even though template forms are built on top of
reactive forms.
They're much harder to extend because of the limited exposure.
If you want to create complex forms, it's much better to work directly with reactive forms.
Template forms were introduced to provide a more straightforward API for those who don't need to configure
every detail.
We spent a lot of time working on the UI of our forums.
Next, it's time to move on to submitting the data to a server in the next section.
We will begin discussing how to perform this action in Angular.
I'll see you there.