Parsley.js: never write a single JavaScript line to validate your forms

235 78 14 years ago

cobalt2760• 14 years ago

Nice lib!

st3fan• 14 years ago

Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?

joeblau• 14 years ago

I didn't write this, but I would say yes. You would have to check twice just incase someone tried to POST directly to your URI bipassing your form page.

why-el• 14 years ago

Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?

mjs7231• 14 years ago

From a Django background which also provides form errors very easily, it seems at first glance that this would not be needed (and it technically isn't). However, it's often nice to the user to let them know of silly mistakes like passwords not matching or invalid emails before they hit submit and get bombarded with everything at once.

Javascript validation provides convenience, not security.

rquantz• 14 years ago

I usually use both for anything public facing. Server side is for security, client side is for UX. keeping it dry is a problem, obviously, but you don't always want the same validations server- and client-side.

rpackard• 14 years ago

Adding client side validations offloads some work from your servers. It could reduce the number of total requests that hit your server and overall increase your speed.

This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization.

Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.

lnanek2• 14 years ago

I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.

Tloewald2• 14 years ago

Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.

djbender• 14 years ago

Could you give an off the top of your head example?

guillaumepotier9• 14 years ago

Parsley's aim is to have think about validation just once back end and seamlessly do the same front end with no extra work. But yes that do not exempt you to validate backend ;)

jmadsen• 14 years ago

At the risk of spamming (since it's my own blog), anyone still wondering about that question should read this or similar tuts - explaining that question and all the basic mistakes people make in validation & security

http://www.codebyjeff.com/blog/2012/12/web-form-security-avo...

Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing

thomseddon2• 14 years ago

The implementation just smacks of AngularJS. In fact, implementing something like this would be just short of trivial using Angular...!

If you like the concept of "extending html" as used here then you should probably checkout AngularJS: http://angularjs.org

jva2• 14 years ago

This looks more like Bootstrap to me. There is no "extending" going on, just adding some data-attributes to the markup.

At first glance, this looks like the best validation library I have seen. It so hard to find validation libs, that don't get into your way.

guillaumepotier9• 14 years ago

Sometimes you just don't have or don't need angular or other js framework and just simply want to validate a form ;)

thomseddon2• 14 years ago

Yes quite, it is nice that is framework independent.

truebosko• 14 years ago

I suppose this is more suited to when your models and schema are also defined on the client side?

Having just hit this situation (validating a form client-side), I found the best solution was to transport the form schema from the server (because I use Django, I can easily whip up a ModelForm), then push that into a simple Javascript Form object which renders the schema and adds validation. Maybe there's better ways, but that's what worked for me. Curious what others have done .. :-)

jva2• 14 years ago

With Rails I did come up with a similar solution to Parley.js. Just add a helper that renders the needed data-attributes and you're done.

Your solution sounds nice for single page apps.

pestaa• 14 years ago

Nice to have a full-blown client-side equivalent of schema definitions and validation rules, but for most of my forms, I just add it quickly and dirty. Sometimes it feels bad, but most web toolkits treat JavaScript as a second-class citizen and not an integrated part of its core (and no, throwing in a jQuery does not count).

Yii framework (PHP) supports validation through Ajax (serializes the form, sends for regular server-side validation and displays the errors on the form). A godsend if your form does not change, and impossible to work with if it is dynamic (consider batch entries with "Add line" features, etc.).

I haven't seen a seamless integration on this higher level.

phpnode• 14 years ago

Yii can also do client side validation (without an ajax call) for most of its built in validation rules.

insin• 14 years ago

Is the form definition-to-JavaScript code open source, by any chance?

I ported django.forms to JavaScript so I could use it with Node.js, but it also runs on the client: https://github.com/insin/newforms

Could be useful to plug the two together.

5vforest• 14 years ago

This is fantastic. The jQuery Validation plugin has needed a successor for a long, long time.

wheaties2• 14 years ago

Yes but then we need all the different validation methods that come with it. I use phoneUS and the like, I don't want to give that up.

guillaumepotier9• 14 years ago

They'll come don't worry ;)

phatbyte• 14 years ago

Loved this

d0m• 14 years ago

Very good, I'll give it a fair try in my next project.

Tloewald2• 14 years ago

Nice.

Improve the demo by removing spellcheck from the name field and capitalizaton for ios (and likely other touch devices) where appropriate.

Along the same lines, demonstrate phone number field (number formatting), currency field, and automatically dealing with urls more nicely.

jiggy20114• 14 years ago

This is a clean way to solve the low hanging fruit of form validation, stuff like isItAnEmailAddress().

What I always find messy in web frameworks is doing validations which are more complicated.

For example a radio button choice which hides another form element which would otherwise be mandatory but should now not be filled in at all. Or where supplying a value between certain dates changes another date field from optional to mandatory and also must check that these dates are between certain values dictated by the first date field.

chime• 14 years ago

For one of my new projects, that is precisely what I am doing - making it possible to define complicated validation rules in a simple manner (and lots more). Would there be interest if we open-source it?

handzhiev• 14 years ago

Of course :)

jiggy20114• 14 years ago

Quite possibly.

Though I'm not sure how much this could be generalised since complex validation rules are effectively computer programs in themselves.

Not sure what your approach to this problem is, but perhaps one way to do it would be a validation engine that is inherently functional by design.

Of course, ideally it should be something that can plug in to popular web frameworks easily.

sergiotapia• 14 years ago

Would love to see something like this, and if it's useful and easy to drop in, I'd use it.

DennisP• 14 years ago

Knockoutjs is nice for that sort of thing. They have a pretty quick tutorial: http://learn.knockoutjs.com/

adorable• 14 years ago

Great. How about internationalization? Do you allow to replace the english error messages with messages in other languages?

znt• 14 years ago

That is what I came here to ask. Is there way to define the error messages somewhere, per language?

guillaumepotier9• 14 years ago

Yes, not very handy currently, but you could override all messages in Parsley constructor on each form..

I'll look definitely into a more handy solution soon :)

niyazpk• 14 years ago

Very nicely done. Beat me to it. :(

I am working on a library which takes a data definition, renders the form and then validates it before submitting it via ajax. It supports various hooks like manipulate the data before submission etc.

IMHO form rendering (in a standard way) is also a common pain point along with form validation. Anyone interested in this type of library? Any inputs will be highly appreciated.

mobweb• 14 years ago

Looks cool, but the demo right at the top of the "examples" page has two things that IMHO aren't as "UX aware" as described on the landing page:

- The "website" field requires the http:// part of the address - After typing three letters into the "message" fieldarea, an error pops up and tells me the message needs to be at least 20 characters long, while I'm still typing away

I realize this could be tweaked by the user but the demo shouldn't have such logical flaws for a script that's described as "Super #UX focused". ;)

guillaumepotier9• 14 years ago

Right. The demo form is totally UX un-aware! :)

baggachipz• 14 years ago

Typo in the "Super Free" section on the home page: s/developped/developed

guillaumepotier9• 14 years ago

thx! will fix that :)

durkie• 14 years ago

thanks so much! very excited to use this in a project we're working on.

jonnytran• 14 years ago

Has anyone had any experience where adding or removing client-side validation has affected conversion?

Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors).

I made a tool that I have server-side form validation. I found that saving the invalid input so that I could examine it later was extremely valuable in understanding what people were entering, so that I could make the tool smarter. A good example is like with Parsley's demo where it requires http:// for the website URL. After seeing that people tried to enter URLs without http://, I knew I could change my code to automatically infer it. http:// is obvious, but a lot of times, people will surprise you. I don't have stats, but presumably this kind of change increases conversion. I realize this anecdote is a different effect than what I'm asking about client-side validation.

mariocesar• 14 years ago

What about a hook where every time a user makes a mistake it sends the related data to a centralized location.

I can envision that could be easily to push this to Sentry https://getsentry.com/welcome/ using the Sentry Javascript Client

kaliblack• 14 years ago

You can do the same thing with Google Analytics events. Use a non-interactive event with "form validation" as category, field name as action and entered value as label. You may miss some events based on the service limits, but the common trends will be obvious.

jiggy20114• 14 years ago

I don't have hard stats on conversions; but I know that when I added some JS to turn form fields a nice green colour when validated filling out the form felt much more satisfying.

vidarh2• 14 years ago

At a past company, we for a period had an (extremely invasive) script hooked up to a form that would log events on every change on the form, keypress by keypress. We could pretty much watch people type by tailing our log for a while... It probably wasn't a very nice thing to do in terms of privacy (I've more than once accidentally pasted stuff into a form that I wouldn't like to submit...), but for the day we did it, it taught us a lot of things about user behaviour we never thought about before (and we made sure to wipe all the data).

E.g. users at the time anyway, had massive problems with dropdown lists (a substantial number of errors were down to users who had clearly started typing, and got what the dropdown moved to as a result of them typing out the correct value). We ended up avoiding them (expiry dates in our billing form, for example).

(This was more than ten years ago, though, so our specific finding might very well be invalid now, with people more used to websites)

I'm not sure how this type of validation would play out. On one hand, if done well, it gives people immediate feedback. On the other hand it gives you no hints about what causes common mistakes like that. I like the idea of logging the values on error...

hazz• 14 years ago

The url validation seems a bit strict, requiring "http:// at the start. No one types that these days, and I think in practice it might be a real roadblock for less computer literate users. I notice also that "ftp://" is valid, but not other protocols like, say, "afp://" or "git://".

Other than that, great job! I'm actually really looking forward to using this in my next project - form validation is usually such a pain.

guillaumepotier9• 14 years ago

I'll take a look to url RegExp validation rule ;)

robomartin4• 14 years ago

This is neat.

A couple of points:

1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side.

2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plugged into their code. This particular tool will, for example, pass "m@apple.comm" as valid.

Other than that, I am sure this is a great time saver.

dinkumthinkum2• 14 years ago

1. I agree, of course. Surely, everyone knows this right?

2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.

jiggy20114• 14 years ago

To fix that, you can do a DNS lookup and check the domain has a valid MX record.

SpoonMeiser• 14 years ago

re point 2.

I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.

I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?

robomartin4• 14 years ago

It's highly application dependent, right?

Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue.

In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use.

Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all.

The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.

jdietrich• 14 years ago

Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped.

"異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.

adamdicarlo• 14 years ago

Why use <input type="text" data-type="email"> rather than... <input type="email"> ? You're already using HTML5 data attributes, so why not use HTML5 input types? Added benefit is that the browser also has an idea of what kind of data goes there - this helps on mobile devices especially, where email fields won't auto-capitalize and might include extra buttons like the ".com" button and "@" right on the normal keyboard.

guillaumepotier9• 14 years ago

Right.

jQuery/Zepto $.data() was fast and easy to implement, rather than searching html5 attr.

I'll think about that ;)

akoeberle• 14 years ago

It shouldn't be that hard to use a attribute instead: var data = $( self ).attr(type);

HugoDias• 14 years ago

I suggest you do add this on cdnjs ;) https://github.com/cdnjs/cdnjs

joseph_cooney• 14 years ago

Looks very similar to the unobtrusive validation used in ASP.NET MVC (which in turn relies on jQuery validation) although this does seem to add richer configuration of behaviour (such as when the validation is triggered etc.)

from here: http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-... <input class="text-box single-line" data-val="true" data-val-length="The field LastName must be a string with a maximum length of 60." data-val-length-max="60" data-val-required="The LastName field is required." id="LastName" name="LastName" type="text" value="" /> <span class="field-validation-valid" data-valmsg-for="LastName" data-valmsg-replace="true"></span>

rickharrison• 14 years ago

This library looks great! I really like the functionality and the html requirement definitions.

I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js

chewxy• 14 years ago

Hey! I use that! Thank you for validate.js. validate.js + humanize.js works very well (but this morning I was considering using parsley.js. I'll evaluate it over the weekend I guess)

tantalor• 14 years ago

"DOM-API" is redundant, as the DOM is an API.

Parsley.js: never write a single JavaScript line to validate your forms

Related Stories