Client-Side Form Validation Minus the Bullshit

Client-side form validation is bullshit and anyone who tells you to just validate on the client-side and let it be is an asshole who needs to be paraded around the office with a sign that says “I don’t care what kind of data our forms accept and I would like to be hacked, please”. But nevertheless sometimes we’re asked to do exactly that (like me for the past week) and because we have to eat we say yes, cringe, and feel a shiver run down our spine right to our core. Then we get over it and write some lame-ass JavaScript. Here’s how to make the most of a bad situation.

The Sitch (As in ‘Situation’)

In my case, we’ve got a third party collecting all of our form data and then running it through their system so the entire company can act on it later. It’s great for certain departments but pure hell for anyone who’s unlucky enough to have to develop for the system.

Here’s what happens:

  1. User fills out a form and hits Submit. Form data is posted…

  2. Form posts data to one of a possible four form processing scripts we host on various servers. And do you know what they do with that data? Send it back out as a POST array using cURL. Okay, well, to this intermediate form’s credit, it does do some basic validation before POSTing that data back out to it’s final destination. But do you know what it does if the data doesn’t pass validation? It chokes and spits up a very plain, ugly page on a totally different URL than the user was on with a message saying “The field X is required. Press the back button”. What the fucking fuck?!?! Press the back button? They’re on a totally different URL now, mind you (not that many computer illiterate people know the difference anyway) and we ask them to press back. Okay, fine. So they press back. But what if they had more than one error on a form? Tough shit! The first validation script will only show you one error at a time. So when you press back and correct your first mistake you’d better hope to god that there aren’t any other errors or you’ll be pressing the back button some more. But I digress… that’s how just retarded our forms are right now.

  3. That retarded form I mentioned in step two sends the data is got back out as a POST request using cURL.

The problem is that the user gets very little feedback about their ability to fill out the form. They don’t know when they’ve made mistakes until after the submit and even then the errors are vague and shitty from a UX perspective. Beyond that it sometimes takes up to 5 seconds for the process to complete (remember, we’re posting to script 1 which then posts to script 2 – over cURL and depending on serverload and the 3rd party processor’s response that can take a lot of time. That’s like at least 3 separate connections that need to be made for a single form submission). With that kind of wait time we often get people clicking the form a trillion times.

We needed a solution. Well, I know how to solve the problem once and for all and for good but they don’t let me have that kind of power so I have to work around a set of constraints. Which leads me to how to do form validation client-side without the bullshit.

Doing the Validation

So since our current validation process sucks, I’m implementing client-side validation which I know is something you should never truly rely on but it’s all I’m allowed to do. So the goal here is to give the user as much feedback as possible before they press submit and to let them know after they submit that the data is being processed and to be patient.

Step 1: Get a no-bullshit JS library

Grab a copy of Parsley.js. It’s awesome. It’s no bullshit.

Stick it in your pipe and smoke it. Or, rather, stick it at the bottom (or top if you’re old school) of your HTML. Reference it somehwere along with jQuery like this:

Include jQuery and Parsley.js
<script src="//"></script>
<script src="parsley.js"></script>

Then create a form and use pure HTML5 for validation:

Code your form using HTML5
<form method="post" action="whatever.rb" name="myform" data-validate="parsley">
  <label for="text-field">Enter text</label>
  <input type="text" name="text" id="text-field" value="" data-required="true" />

  <label for="email">Enter email</label>
  <input name="email" type="email" id="email" value="" data-required="true" data-type="email" />

  <button type="submit" id="submit">Submit</button>

Now Parsley just takes care of the rest. Seriously. Just try to submit that form without filling it in! Here, have a look at this demo embedded below for your convenience:

As you can see from the fiddle, I’m taking care of our problem with multiple form submissions! I’ve loaded jQuery on the page (I did this to use Parlsey.js anyway though it also comes with a vanilla JS version) and I’m using a couple real short functions to make sure people don’t go nuts and submit the form a trillion times. The natual question at this point would be “what if they make a mistake and need to submit again?”. I got that covered. So when the submit button is press, it becomes disabled. Assuming that the form data is valid there’s no need for it to ever become active. However, in the case that Parsley detects an error, it’ll throw that error right under the form fields, stop the form from being submitted, and our button becomes inactive now as well (we disabled the button here, Parsley only stops submissions and throws errors). So presumably if the user has to correct the form they won’t be able to submit it again because it was disabled on the click event. Not so! I’ve got a second function that re-enables the button when a user clicks an input field. Is this method bullet proof? No way! There are a few holes not including simply disabling JavaScript. However, given the set of constraints I had to work with, this is a pretty good solution and is now in production. There are a few edge cases where it causes problems and Internet Explorer doesn’t always like to disable your buttons depending on what other JS is running on any given site but it works every time most of the time.

Now, of course we really should be doing validation server side and giving our users far better feedback when the server detects a problem but hey, sometimes when you work for a company of a certain size no one wants to listen to the guy who knows what he’s talking about so this solution will just have to do.

Check out Parsley.js. It’s seriously the easiest (client-side) form validation library I’ve ever used!

Web development

« How Keys Work Now Powered 100% By Ruby »