2.2 Introducing the Constraint Validation API

In the previous lesson I introduced you to the built-in form validation features in modern browsers, and it is a wonderful thing. And I can say that because I have spent countless hours writing form validation code. It's not fun- In fact, I can think of quite a few other things I would rather be doing than writing form validation code. And a lot of the problem was trying to find the best approach because were so many approaches to writing form validation code. But now we don't have to worry about that because the browser fricking does it for us and that is wonderful. So if you want to use the built in capabilities feel free. It's there. You can take the time that you would normally have to apply towards form validation and make something else in your page or application just that much better. However, there are a couple of reasons why you might not want to use it and the first is that the browser might not support. Now we thankfully live in a world where the modern browsers mostly support the same stuff, you know Chrome, Edge, Firefox Opera for the people that use it. They all support the main important things and form validation is one of them. So, if our target audience are just those browsers than we're golden. However, we still live in a world where Internet Explorer is used and I have to be honest, I don't really remember what Microsoft started to implement after version nine. So, 10 and 11 are kind of a blur to me. I do remember that there were some issues with form validation, in those versions. So I am just going to say that's okay, if we've to support version 10 and 11. Relying upon the built in support, probably isn't a good idea. So that would be the first reason, the second reason would be the look and feel of the page or the application. For example, let's first of all get rid of this background color cuz that's awful. Usually, I would think of a light red background for the invalid fields, so something that would look boot strappy, because we're using Bootstrap. And, in fact, I'm kinda surprised that something isn't built in already. But, you know, whenever we click on the Send Message button, we get this little pop-up, which is nice, I mean, that's great, however, it kinda takes us out of the experience. Of the page and application, and a lot of times user experience is very important so that would mean that we would want to be able to customize the form validation experience in which case we would have to write Java Script. So for older browsers, we have to write Java Script. For customization, we have to write JavaScript. But thankfully, we don't have to write merely the same amount of JavaScript that we used to because we have something called the constraint validation API. This is a feature that's really ties into the built in form validation that we've already talked about. So that means that we can use the required attribute. That means that email fields are still checked to see if they are valid email addresses. So we no longer have to write the code that's going to check all of that stuff. Instead, we just have to see if the form itself is valid. And then determine what isn't valid, which is actually quite easy. But wait a sec, what about older browsers? If the constraint validation API relies upon these built in capabilities, older browsers aren't going to have it. Well that's something else. There are many poly fields available for the constraint validation API. So we can use a poly fill in the older browsers write the same JavaScript code and we are good. So that's what we are going to start looking at in this lesson. The first thing that we have to do then is tell the browser that thanks for doing this but we don't want you, to validate our form anymore, and we do that very easily by adding an attribute to the opening form tag called no validate, and that is going to tell the browser not to validate the form. So if we submit this again, we're going to see that it does submit and there was no validation. We didn't see a pop-up message. There is nothing. Now, we get to write the code that's going to at least check to see if our form is valid. Let's put our JavaScript inside of a different file. So, let's create a new file. Let's call it formval.js and we of course want to reference this inside of our HTML. So, let's have a script element. The source attribute will be formval js, there we go. So inside of our JavaScript's, let's start with an immediately involved function because that's just good practice to do. And let's work primarily with the email field. Eventually we will work with everything else but for right now let's just focus on the email fields. So we will grab that element object with the getElementById method. And then we will listen for the input event. So that anytime that we type into the field then this event is going to fire, and that's going to give us an opportunity to check to see if this field is valid or not. And we do that very easily with our element object email. And then we have a property called validity and this is actually a type of object called validity state. That's a little difficult to say, so let's do this we're going to write the validity state object to the console so that we can then inspect it. So let's put the console let's submit the form, actually we don't have to submit, we are handling the input events. So, if we just type in to it we're going to see the first entry here. The validitystate has many properties, badInput, customError, patternMismatch, rangeoverflow, all of these are properties for certain types of validation. Now we are working with an email address. And you might think that the bad input would be for that type of validation, but it's not. It's type mismatch. And that makes sense because the form or the form field that we were working with is a type of email. And the value that we have typed into it is not an email. So there is a mismatch between the type of data that we've typed in with an email address. But as we start to fill this out, and we make it look like a valid email address, we're going to see that, that tight mismatch is now false. Now also notice that there is this valid property and we can see that it is true. If we look at any of the other entries here we're going to see that it well it says that's true too. Well anything after the at sign. It would be true, I would think so. Here we go, the first one the valid is false. So the type mismatch was true but the valid was false. So then in order to determine if this is a valid email, all we have to do then is say, if email.validity.valid if that's true, then we want to submit the form. But I would actually write it like this. If the validity is not valid, then we want to prevent the default from occurring, and let's go ahead and let's alert something. We'll say that the email is invalid, now that's not going to make my point as far as user experience is concerned, we will focus on that at another time. But now and this is actually going to be quite awful, but if we type we see email is invalid and we're going to see that every time until we have what it thinks is going to be a valid email address and that is unfortunate after the @ sign I said earlier. So anything after the @ sign, although the dot didn't, okay, so there we go. So now, well, I hit an invalid character but we can see that we have a valid Email address so we're not seeing that message displayed anymore. So in the next lesson we are going to take this idea of using the constraint validation API and we are going to make it work better within our form. I guess the next thing that we need to do is display our error message so that it doesn't do it within an alert box. But we also need to handle the forms submit event because we definitely don't want the form to be submitted if the Email field is invalid so we all do all of that in the next lesson.