In this lecture, we are going to improve the user experience of our forum at the moment.
The error messages will appear instantaneously.
I have the form opened in my browser without touching a single field.
The error from the required validator will appear.
It's sort of annoying.
We don't want to annoy our users with error messages when they haven't had a chance to fill out the
form.
Error messages should be presented after typing inside the input field anglers reactive form.
This feature can help us detect actions on the field.
In the resource section of this lecture, I provide a link to the abstract control class.
Strangely, I'm not providing a link to the form control class, the abstract control class is the parent
class of the form control class.
In some cases, you may not find the information you're looking for in a specific classes documentation
to find what you're looking for.
You may need to check if the class inherits another class.
The abstract control class has the documentation for the properties we're about to use.
If we scroll down this page, we will find a section called subclasses.
According to the documentation, the form control and form group classes are subclasses of the abstract
control class.
Properties and methods under this class can be found in our controllers and groups.
The information on this page is relative to what we need.
Scroll down to the properties section.
From this list of properties, there are various properties for helping us detect various interactions
on an input.
For example, there's a property for when an input has been touched.
We can use them to help us change the behavior of our error message.
Here are some of the essential properties.
Every single property in this list is a Boolean value.
The first property is called valid.
This property will tell us if a controller is valid.
If a validator returns an error, angular will automatically update this property.
This behavior goes for the other properties to.
They're managed by angular.
We should treat them as read only properties.
The next property is called invalid.
It holds the opposite of the value of a valid property.
It'll tell us if the controller is invalid.
Afterward, we have the disabled property.
In some cases, angular may disable a controller.
Disabled controllers do not get validated by angular.
We can check if validation is disabled with this property.
Up next, we have the touch property.
Input elements can emit an event called Blur.
The blur event is emitted after an input has been clicked on and then clicked away.
If this event is emitted, Angular will toggle this property from false to true.
Subsequently, we have the untouched property.
This property is set to true after the Blur event.
This property will be toggled to false.
This property is followed by the pristine property.
It'll tell us if the initial value hasn't changed.
The opposite of this property is the dirty property.
Some students tend to be confused about the difference between the dirty and touched properties.
They both will have an initial value of false.
The touch property is set to true if the user clicks on the input and then clicks away from the input,
whereas the dirty property will be set to true.
Once the value changes.
Let's start using these properties.
We are going to use the touched and dirty properties to help us render the error message.
If both properties are true, we should output in error.
Our goal is to display an error after the user fills out a field.
These properties are perfect for this scenario.
Open the register template file.
We will update the condition on the first paragraph element.
It's going to be a long condition.
We will insert the condition at the beginning of the tag.
The condition will be the following register form controls dot name, dot touch and register form dot
controls, dot name, dot dirty and.
The error message will get rendered if the following three conditions are true the inputs, initial
value has changed, the inputs been touched, the inputs value has failed validation.
We will copy the conditions over to the other error message for the minimum length validator.
In my opinion, our template is starting to become cluttered.
You may feel the same way.
We will fix this soon.
First, let's test our conditions.
Open the registration form in the browser.
Without touching the inputs, nothing appears.
The behavior has completely changed.
If we touch the input, nothing changes next.
If I type a single character and move away, an error appears great.
We've got the behavior we were looking for in an upcoming lecture.
We will address the mess in our template.