- Read Tutorial
- Watch Guide Video
Now that we have our form in place it's time to actually start building some validations in to make sure that when a user creates a proposal that it's valid. We have a number of required statements here, but these are really just kind of one part of what's needed because we can have required statements all we want. However if we don't put the validations in place to let users know what's wrong then we're not really doing a good job. So what I'm going to do is if you've ever been on a form where you started typing content into the form and say you did something that was wrong like type in the wrong character or didn't fill in a required field. I want to dynamically show users if they're doing something wrong in the form. So a good example of this can be in our customer name. This is required, as we can see right here
and we're going to borrow some things from ngForm. This module here gives us some great tools that we can use to implement validations.
I'm going to create a div and I'm going to create an outlet for it. So if you remember how we have our ngModel right here
and how it has brackets and has parentheses which means that this is reading data in the brackets mean that you can read data in from the component. The parentheses mean that you can set values. Well for this we want to read values in. So we're only going to use brackets and this means that anything that we put connected to an equal sign right here is going to be evaluated like regular Javascript. So I'm going to say hidden and then set this equal to customer.valid and also inside of here I'm going to do the double pipes which stands for "or" so this is a conditional. Then I'll say customer pristine.
<div [hidden]="customer.valid || customer.pristine">
And that's all we're going to do inside of this div. So what this is doing, because if you've never seen this before this before it looks really foreign and this is something that is supplied via Angular. So Angular gives us this hidden value which means that we want this div to remain hidden. So in other words, users should not be able to see this div unless we have a customer valid or it's a customer pristine. Which means that if we have a valid customer and in this case what that means is that some text is in there we don't really have a lot of validations we just make sure that the user enters in some kind of text inside of here or customer.pristine.
Pristine, if you notice is not an attribute that we have. What it is is simply a state that angular looks for with the form. So if we didn't have this in we would get some kind of annoying values because I've seen this happen before with some kind of poorly created forms where the developer forgot to put customer pristine or whatever the data element was in pristine and the validation started as soon as the page loaded. Say a customer name is required, it would actually show an error message even though the user hadn't done anything. So what pristine does is check to see has this input been touched at all? So has someone gone in and started typing? And if so then it's no longer pristine. So the only way that this value whatever we put inside of here and what I'm going to put is "Customer name is required."
The only way that this is shown is if the customer is not valid or the customer attribute is not pristine. Meaning that someone went in and typed inside of it.
I'm going to hit save and as you can see nothing changes here. Watch what happens if I come in to the form and I type in Google. Everything works properly. But now watch what happens if I go back and I delete it. You see how automatically it pops up our validation and our validation says customer name is required? Now if I type in Yahoo our validation goes away again. So this is perfect.
Now let's see what would happen if I got rid of this customer pristine component. As you can see it says customer name is required. And there may be times where you want to have this. You may want to have the validation right away so that it goes away when you type it in. However for our sake what I want is to have this hidden unless both of these are false. That's kind of a dead simple way of implementing validations. Let's copy this down for each one of these that are required. So we'll say that a portfolio URL is required. And this one's going to be portfolio URL instead of customer. We can test this out. This one's going to be an easy one because the only way that this would not work is if someone actually went and deleted the URL there. And that one is pretty straightforward. And then we have tools. So this one will say that "A list of tools is required." Grab tools. Have that swapped up. Make sure you always change those values.
Next ones estimated hours. Let's change it up. We can say, "You need to enter your estimated hours for the project." And this one's going to be estimated hours.
Part of the nice thing, because you may think that there's some duplicate code going on here, but not really because this gives us the ability to have very granular control on each one of these validations because you may have some where you may want to say required, so you can get rid of pristine there and also have a specific error message for each one. You could technically create an entirely new component that could encapsulate all of this and then just call the component right here.
If this became a very large application and you wanted to get down into a granular way of refactoring it and getting rid of any code duplication you could do something like that. But for right now and for our sake we're just going to create a unique one for each element.
We can say you need to enter your hourly rate for the project. Then weeks to complete, this is going to be pretty much the same. Need to enter the weeks you estimate to complete the project. This last one is optional so we're not going to put a validation there. So now if I hit save, let's come to client e-mail. If I come here. Delete it. Nothing happens. If I do complete and type in two weeks to complete but then go back it says you need to enter the weeks you estimate to complete the project. (He is filling out the forms to show how they work in real time.)
Each one of these look like they are working properly. So very nice job. If you went through all of that. This is a great way of being able to implement validations and to kind of review what we have built here. We created an outlet here with hidden. So this is checking to see if the customer is valid or the item has never been touched. And if these gets triggered, in other words if it's not valid or if the user clicked on the item, entered some things in but then deleted it then this is going to pop up. Otherwise if the form remains valid at all times these validation messages should never be shown on the page. And this is a really cool way of doing this because if you're coming from a Rail's development kind of background then you know that the only way usually that you'd have these validations come up is when the user clicks on submit and it has to go communicate with the server and that's a perfectly fine way of doing it however, to me this is a lot cooler. This is a really great way of doing it because here you're able to give the user feedback while they're in the form before they even hit submit or before they even think about communicating with the server, and you can handle all of your data validation right here.
Now with all of that being said it's still important to have validations on the server side because one thing that a very savvy user could do is they can right click and click inspect and they could come here and add all kinds, they could actually delete some of this code. They're obviously not deleting the code in your application but what they're deleting is their instance. They're deleting what the browser is rendering and so you could go and delete that and then submit the form and it would bypass these validations. So these validations are really not as much validations and not really blocking the user from doing anything they're just informing the user on which items are required and which ones aren't. So you always have to make sure that you're pairing up your client side validations which that's what these are when you put required here and you put error messages just like this. These are called client side validation. So it's always important that you pair those up with server side validation so that you're protected on both sides and you can't have a savvy hacker get in and be able to bypass all of your data validations.
That is how you can implement data validations along with error messages and dynamically show those to your users.