In this lecture, we are going to handle the errors generated by our custom validator.
Unfortunately, there's a bit of a problem with how we've implemented the validator to understand why.
Let's check out our form in the browser.
I'm going to type a value inside the password field.
This value will immediately trigger an error from our custom validator.
The error gets logged below the form.
The error is added to the form group.
It's not added to a control, which can be a problem.
The goal is to render an error message below the confirmed password field.
However, the confirmed password field is not informed of the error.
We can use the developer tools to verify this behavior.
Open the angular developer tools.
Under the register component, select the form element.
We are going to be digging deep inside this elements, properties open the form controls, reconfirm
password Dot Ayres object.
It can change in air, but not from our custom validator.
It says the value is required.
I'll type in a value inside the confirm password field.
After doing so, the error property is set to null.
It's not aware that the password fields don't match.
We need to inform the control of an error from the form group.
Otherwise, we will not be able to render an error below the input.
Alternatively, we could render the error in the alert component.
That would be easier.
But in my opinion, less effective.
Fortunately, angular makes it super easy to add errors to controls.
Let's get started.
Open the register validators file.
Angular manages errors on our behalf.
It'll update the errors property on a group or control based on the value returned by a validator function.
In some cases, we may want to manually add an error.
Every control and group has a function for manually adding errors below the error variable in our function.
We will call the set errors function on the matching control object.
The set airs function has one argument, which is the air to add a control.
Optionally, we can pass in no to remove errors.
Let's pass in our errors variable.
With one simple function, we've added an error to our control.
There's one important point I want to make by using the set errors function, we're responsible for
managing errors.
Angular will not remove the error.
If we manually add an error, we should remember to remove an error when a field is valid.
The errors variable will either store an error object or null.
Since our custom validator function will run on every key press, we will constantly be updating the
control.
Even though we're setting the error on the control, we are going to continue to return the error.
If another developer wants to handle the error on the group, they will have that option before moving
on to rendering error messages.
Let's handle the other error in our validator above the variables.
We are adding a conditional statement.
These conditions will check if the controls were found in the group.
If either of the controls can't be found, we will return in error.
This type of error is for developers, not users.
We should output an error message in the console to inform developers of the error above the return
statement.
We will call the console Typekit error function to output the following message Form controls cannot
be found in the form group.
We will leave the return statement inside the conditional block for the same reason as before.
If developers want to handle the air in the templates, they will have that option.
Let's move on to adding an error message for this validator.
Open the input template file.
We created this component to handle errors for input.
We are using it in our registration form at the bottom of the template.
We have a series of messages for different validators.
Let's make one copy of these messages.
The condition will be updated to check if the no match property is on the airs object.
As for the message, it'll say the following passwords do not match.
There's one last step.
We have logged the error below the form, we should remove it now that we have a proper error message.
Open the register template file.
At the bottom of the template.
Remove the expression.
Let's give our form a test.
We will need to type inside both password fields to trigger the error our input component will not render
an error message until both components have been touched.
After doing so, the error message appears perfect.
Let's try inputting matching values.
The errors have gone away.
We've successfully validated the input with a custom validator.
We can move on to validating the email field with an asynchronous validator, which presents a set of
different problems.
Let's tackle this validator in the next lecture.