Learning A Way to Validate in Javascript

I want to show an example of a situation where I had a design and some validation derailed it. I Knew how to check if a user had bad inputs and so I flew forth with writing software. I needed to make a table that enables a user to validate that they will indeed by what they owe within the next 30 days. But what I did not think about was what if the user just hit enter. What if he disregards what I as the developer think is an obvious workflow for doing what you need to do. It looks like this.

Ok, not very interesting, and kinda a weird component, but what the acceptance criteria says, goes. The gist is for the user to select on invoice that is pasted due by clicking the confirm to pay and then selecting a date from a date picker that the payment will be sent out by. I get the data from SalesForce who get the data from another service. I use Angular and ng-repeat through it on a table. That is all. Looks a little like this.

//Only if the status is "Past Due or Default" call the service
if (invoiceStatus !== “Current”) {
//call the service and pass a needed contract number
invoiceService.getInvoices(pulledContractNumber).then(function (resp) {
response = resp.pastDueInvoiceResponseList;//assign response
     //here I add some properties to the response for validation
angular.forEach($scope.response, function (value, key) {
//if the playment is confirmed
if (value.datePaymentToBeSent) {
//use this to denote the invoice has been paid
value.confirmed = true;
//if confirmed is true. Bound to the table
value.promiseStatus = “Promise to pay sent”;
//with this property I ignore the object on submit
value.ignoreOnSubmit = true;
else {
value.confirmed = false;
value.promiseStatus = “”; //binds a blank field
value.ignoreOnSubmit = false; //evaluated on submit
//assign the response to a scoped variable to be repeated on page
$scope.displayData = response
});//end invoice service

That is the basics of getting the data and preparing it with a couple of extra properties I use to identify if a payment has been sent or not for an invoice.

The real challenge comes in when the AC politely asks for validation to be rendered so the user knows when he has not given all the needed information to submit a promise to pay. The goal was something like this.

Straightforward. The difficulty was what if the user just hits submit? I need to throw an error, but how do I tell if a user hit submit without giving any information, or if he only filled out one invoice to submit (which is ok because they don’t have to promise all payments at the same time)?

Angular uses a dirty vs pristine concept. If the user touch a form or input, it is “dirty”, if they have yet to, it is pristine. They do this by applying css classes the the elements. I found myself in a similar situation, so I used an array to simulate this idea. There are four outcomes of a user interacting with this table. A success, a failure to check the box but pick a date, a failure to pick a date but check the box, or the user just hits submit. The first three I consider dirty and the last pristine. So I use two arrays: a validation message array and a pristine/dirty array. I block the submit if the length of the validation message array is greater than zero. That part made sense to me, but still how was I going to tell the the table was pristine and assign an error to the validation message array? It looks a bit like this (also check out the screenshot above. Below is more for having access to the text if desired).

function validateRecords(records, messages) {
//validation state dirty/pristine array
var selected = [];
//array of total errors
var invalidSubmissions = [];
angular.forEach(records, function (value, key) {
//set the validation state to dirty. Will return false and return Invoice not selected error
if (!value.ignoreOnSubmit && !value.confirmed && value.datePaymentToBeSent) {
messages.push(“Invoice not selected. “);
//set the validation state to dirty. Will return false onSubmit
else if (!value.ignoreOnSubmit && value.confirmed && !value.datePaymentToBeSent) { //
messages.push(“Payment date was not set. “);
//set the validation state to pristine meaning the row not touched
else if (!value.ignoreOnSubmit && !value.confirmed && !value.datePaymentToBeSent) {
//set the validation state to dirty. If is valid return true
else if (!value.ignoreOnSubmit && value.confirmed && value.datePaymentToBeSent) {
//count the number of pristine rows in the selected state array
countPristine = [];
function countInArray(array, what) {
var count = 0;
         for (var i = 0; i < array.length; i++) {
if (array[i] === what) {
return count;
//if all rows are pristine, throw error and return false
countPristine = countInArray(selected, ‘pristine’);
if(countPristine === selected.length){
messages.push(“Invoice not selected and payment date was not set”);
if (invalidSubmissions.length > 0) {
return false;
return true;

So this is pretty hard to read. And it is not a super clear picture. I am sure there is an easier way to do this, but I still wanted to share one concept here. If you are developing your skills as an engineer, don’t be afraid to improvise and meet the AC. The software needs to be written, and refactor can happen after code review. Here is a way to take a concept used to get out of a tough situation of not knowing what to do next. Now I have an error that looks like this.

Cool. My component does its thing and lets you know when you need to do yours better. It meets AC and closes out a defect. Probably needs a code review, but at it will make the release schedule. Learning to write software can be hard. Looking at code like this can expose you to ideas. I think that is good.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.