4 ms·

Show HN: validate.js - lightweight JavaScript form validation library

102 points by rickharrison 15y ago

ceejayoz 15y ago
A quibble: it's validator, not validater. Pull request sent.
- rickharrison 15y ago
  Thanks for letting me know. I just pushed up 1.0.1 with this renamed.
kornork 15y ago
Interesting... is inline validation an option on this?
- neovive 15y ago
  Inline, instant validation would make this very useful as a compliment to full server-side validation. I agree that client-side validation can significantly improve the ux for forms.
  - ams6110 15y ago
    I like LiveValidation http://livevalidation.com/ http://livevalidation.com/
- rickharrison 15y ago
  It isn't in there yet, but that is definitely something I wanted to add.
LeafStorm 15y ago
This looks great. Though I think the validators list should probably be an actual array of validators instead of a pipe-delimited string.
- rickharrison 15y ago
  I debated this for a while. In the end, I ended up going with the CodeIgniter style of piping. I may just add support for both.
kgtm 15y ago
While client-side validation provides a possibly snappier user experience, developers should constantly be reminded that the client cannot be trusted. Data integrity checks and conformance validation that matters must take place at the other end of the transaction.
- rickharrison 15y ago
  I completely agree. I will probably add a note in the docs to remind people that you should always still perform server side checks.
  - btucker 15y ago
    It would also be cool if there was some documentation on how you might use validate.js in concert with server-side validations.
    - javanix 15y ago
      There isn't really any way to dovetail client-side validation with server-side validation. Client-side validation should always be assumed to be disabled completely - view it as merely a convenience for your users. Help them switch dates into a correct format, make sure their userids aren't taken before they finish filling out their forms, that sort of thing.
      - aaronblohowiak 15y ago
        >There isn't really any way to dovetail client-side validation with server-side validation I think the parent of your comment was talking about using SSJS to re-use validation on both ends of the pipe.
        rickharrison 15y ago
        I will be adding server-side js support, so this will be a definite use case.
alttag 15y ago
I've seen several projects named "validate.js". May I suggest coming up with a different name to let devs know which of the several libraries by that name they're working with? ("valid8.js" is already used too)
miles_matthias 15y ago
I really like seeing simple utility libraries like this be posted on github. It makes everyone's sites better when a lot of people contribute to a good library. Nice job, and kudos for working with everyone on pull requests.
- rickharrison 15y ago
  Thanks :) I look forward to more pull requests coming in.
rimantas 15y ago
No support for HTML5? (by that I mean support for "required", "pattern", "min", "max" attributes).
- rickharrison 15y ago
  Not yet. This is just a first version that I wanted to get out to see what people thought. From here, I can start working on features like HTML5.
przemoc 15y ago
You may consider adding more sophisticated validation routines. Check my ruby snippet for possible inspiration: https://gist.github.com/571093 https://gist.github.com/571093 (IBAN, ISBN, ISSN, VATIN and some other numbers used in Poland)
oinksoft 15y ago
I think you should have params to the validators, specifically for the regex case, in which the callback_ approach, with registration and such, is quite onerous. { rules: 'regex', params: { regex: [/abc/] } } or, { rules: 'regex:^foo' }
- rickharrison 15y ago
  I like this idea a lot. I chose to start out with the callback_ approach due to trying to mimic the CodeIgniter API. However, this would be much easier especially for just a regex.
alexyoung 15y ago
Have you thought about supporting JSON Schema? (http://json-schema.org/ http://json-schema.org/)
y0ghur7_xxx 15y ago
How does this compare to jQuery validate¹? I use that a lot and it works great. Did you write this because you didn't wart the dependency with jQuery? ¹http://bassistance.de/jquery-plugins/jquery-plugin-validation/ http://bassistance.de/jquery-plugins/jquery-plugin-validatio...
tomelders 15y ago
seems like the right place to shamelessly plug VRS, which is something I really need to pick up again http://vrs.tomelders.com/index.php?title=Main_Page http://vrs.tomelders.com/index.php?title=Main_Page The hope is that one day, browsers could have a native VRS implementation, and until that day Javascript and serverside scripting could pick up the slack.
jqueryin 15y ago
While we're on the topic of lightweight JS validation libraries, I released my own and have used it for well over a year on a number of production sites. It's quite feature rich and also very low on LOC. It already includes much of the support you guys mentioned here, including live validation and support for passing params. It's garnered towards those already utilizing jQuery sitewide who like things short and sweet. You can override and customize everything, but it also provides you with decent defaults. Salid - The Simple jQuery Form Validator http://www.jqueryin.com/projects/salid-the-simple-jquery-form-validator/ http://www.jqueryin.com/projects/salid-the-simple-jquery-for... The version I use now is tweaked with improvements. I'll gladly share it; I've just been busy and not posting much to the site. If you see problems with the validation methods, they've been fixed over the year in the new version.
nickburlett 15y ago
I feel that the individual fields that have errors should be highlighted. While it's useful to say "The password field is required." at the top, it's more obvious to the user when the password field itself is highlighted in some way. A quick visual scan of the fields then lets you know where action needs to be taken.
- FuzzyDunlop 15y ago
  It gets a +1 for being a non-jquery solution (jquery's fine for abstracting the DOM for animation and UX niceties, but you don't need to include what adds up to 2000 lines of code uncompressed just to find the contents of a text field and compare it), but this is the clincher. The actual field that doesn't validate needs to be highlighted, because otherwise the disconnect between the error and the source makes it difficult to actually identify the source. The only other thing it needs is to position the error message adjacent to the invalid field. When HTML5 is implemented better these things could be used more effectively. But HTML5 validation as it is now isn't useful until you can style the browser's errors. It might be a better idea to hold off on the HTML5 stuff and work on polishing up the output :) Unless there's more control over the fancy new features now.
skeptical 15y ago
I don't this this is much use because it's pretty much made to be a stand alone library. I think what we all want int 2011 is a ways to lift validation rules from the server to the UI automatically. Otherwise we still obviously need to do all the work on the server. Maintain two parallel sources that need to match their behavior is PITA.
posabsolute 15y ago
There is also the validationEngine ! not that i'm a developer on it https://github.com/posabsolute/jQuery-Validation-Engine https://github.com/posabsolute/jQuery-Validation-Engine
cdsanchez 15y ago
Have you thought about adding support for boolean operators in the rule declarations? For example, "empty||valid_email" => "empty or a valid email", or "valid_email&&matches[email]" => "valid email and matches the 'email' field"? Basically, support for !, && (easy since this is the default behavior), and ||. To be honest, the use cases for this functionality is pretty limited but I think it'd be a nice feature to add just for the sake of practice. It would make handling error messages a little more complex though. I tried to add something like this to a small validation library I wrote about a year ago. I think that part worked pretty well but otherwise it wasn't very well designed. Another problem I ran into was the lack of support for rules that depended on asynchronous operations.

102 points by rickharrison 15y ago

ceejayoz 15y ago

A quibble: it's validator, not validater. Pull request sent.

rickharrison 15y ago
Thanks for letting me know. I just pushed up 1.0.1 with this renamed.

kornork 15y ago

Interesting... is inline validation an option on this?

neovive 15y ago
Inline, instant validation would make this very useful as a compliment to full server-side validation. I agree that client-side validation can significantly improve the ux for forms.
- ams6110 15y ago
  I like LiveValidation http://livevalidation.com/ http://livevalidation.com/
rickharrison 15y ago
It isn't in there yet, but that is definitely something I wanted to add.

LeafStorm 15y ago

This looks great. Though I think the validators list should probably be an actual array of validators instead of a pipe-delimited string.

rickharrison 15y ago
I debated this for a while. In the end, I ended up going with the CodeIgniter style of piping. I may just add support for both.

kgtm 15y ago

While client-side validation provides a possibly snappier user experience, developers should constantly be reminded that the client cannot be trusted. Data integrity checks and conformance validation that matters must take place at the other end of the transaction.

rickharrison 15y ago
I completely agree. I will probably add a note in the docs to remind people that you should always still perform server side checks.
- btucker 15y ago
  It would also be cool if there was some documentation on how you might use validate.js in concert with server-side validations.
  - javanix 15y ago
    There isn't really any way to dovetail client-side validation with server-side validation. Client-side validation should always be assumed to be disabled completely - view it as merely a convenience for your users. Help them switch dates into a correct format, make sure their userids aren't taken before they finish filling out their forms, that sort of thing.
    - aaronblohowiak 15y ago
      >There isn't really any way to dovetail client-side validation with server-side validation I think the parent of your comment was talking about using SSJS to re-use validation on both ends of the pipe.
      - rickharrison 15y ago
        I will be adding server-side js support, so this will be a definite use case.

alttag 15y ago

I've seen several projects named "validate.js". May I suggest coming up with a different name to let devs know which of the several libraries by that name they're working with? ("valid8.js" is already used too)

miles_matthias 15y ago

I really like seeing simple utility libraries like this be posted on github. It makes everyone's sites better when a lot of people contribute to a good library. Nice job, and kudos for working with everyone on pull requests.

rickharrison 15y ago
Thanks :) I look forward to more pull requests coming in.

rimantas 15y ago

No support for HTML5? (by that I mean support for "required", "pattern", "min", "max" attributes).

rickharrison 15y ago
Not yet. This is just a first version that I wanted to get out to see what people thought. From here, I can start working on features like HTML5.

przemoc 15y ago

You may consider adding more sophisticated validation routines. Check my ruby snippet for possible inspiration: https://gist.github.com/571093 https://gist.github.com/571093 (IBAN, ISBN, ISSN, VATIN and some other numbers used in Poland)

oinksoft 15y ago

I think you should have params to the validators, specifically for the regex case, in which the callback_ approach, with registration and such, is quite onerous. { rules: 'regex', params: { regex: [/abc/] } } or, { rules: 'regex:^foo' }

rickharrison 15y ago
I like this idea a lot. I chose to start out with the callback_ approach due to trying to mimic the CodeIgniter API. However, this would be much easier especially for just a regex.

alexyoung 15y ago

Have you thought about supporting JSON Schema? (http://json-schema.org/ http://json-schema.org/)

y0ghur7_xxx 15y ago

How does this compare to jQuery validate¹? I use that a lot and it works great. Did you write this because you didn't wart the dependency with jQuery? ¹http://bassistance.de/jquery-plugins/jquery-plugin-validation/ http://bassistance.de/jquery-plugins/jquery-plugin-validatio...

tomelders 15y ago

seems like the right place to shamelessly plug VRS, which is something I really need to pick up again http://vrs.tomelders.com/index.php?title=Main_Page http://vrs.tomelders.com/index.php?title=Main_Page The hope is that one day, browsers could have a native VRS implementation, and until that day Javascript and serverside scripting could pick up the slack.

jqueryin 15y ago

While we're on the topic of lightweight JS validation libraries, I released my own and have used it for well over a year on a number of production sites. It's quite feature rich and also very low on LOC. It already includes much of the support you guys mentioned here, including live validation and support for passing params. It's garnered towards those already utilizing jQuery sitewide who like things short and sweet. You can override and customize everything, but it also provides you with decent defaults. Salid - The Simple jQuery Form Validator http://www.jqueryin.com/projects/salid-the-simple-jquery-form-validator/ http://www.jqueryin.com/projects/salid-the-simple-jquery-for... The version I use now is tweaked with improvements. I'll gladly share it; I've just been busy and not posting much to the site. If you see problems with the validation methods, they've been fixed over the year in the new version.

nickburlett 15y ago

I feel that the individual fields that have errors should be highlighted. While it's useful to say "The password field is required." at the top, it's more obvious to the user when the password field itself is highlighted in some way. A quick visual scan of the fields then lets you know where action needs to be taken.

FuzzyDunlop 15y ago
It gets a +1 for being a non-jquery solution (jquery's fine for abstracting the DOM for animation and UX niceties, but you don't need to include what adds up to 2000 lines of code uncompressed just to find the contents of a text field and compare it), but this is the clincher. The actual field that doesn't validate needs to be highlighted, because otherwise the disconnect between the error and the source makes it difficult to actually identify the source. The only other thing it needs is to position the error message adjacent to the invalid field. When HTML5 is implemented better these things could be used more effectively. But HTML5 validation as it is now isn't useful until you can style the browser's errors. It might be a better idea to hold off on the HTML5 stuff and work on polishing up the output :) Unless there's more control over the fancy new features now.

skeptical 15y ago

I don't this this is much use because it's pretty much made to be a stand alone library. I think what we all want int 2011 is a ways to lift validation rules from the server to the UI automatically. Otherwise we still obviously need to do all the work on the server. Maintain two parallel sources that need to match their behavior is PITA.

posabsolute 15y ago

There is also the validationEngine ! not that i'm a developer on it https://github.com/posabsolute/jQuery-Validation-Engine https://github.com/posabsolute/jQuery-Validation-Engine

cdsanchez 15y ago

Have you thought about adding support for boolean operators in the rule declarations? For example, "empty||valid_email" => "empty or a valid email", or "valid_email&&matches[email]" => "valid email and matches the 'email' field"? Basically, support for !, && (easy since this is the default behavior), and ||. To be honest, the use cases for this functionality is pretty limited but I think it'd be a nice feature to add just for the sake of practice. It would make handling error messages a little more complex though. I tried to add something like this to a small validation library I wrote about a year ago. I think that part worked pretty well but otherwise it wasn't very well designed. Another problem I ran into was the lack of support for rules that depended on asynchronous operations.