This is fantastic. The jQuery Validation plugin has needed a successor for a long, long time.
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.
Parsley.js: never write a single JavaScript line to validate your forms
61–70 of 80 posts
Re: Parsley.js: never write a single JavaScript line to validate your forms
#62Re: Parsley.js: never write a single JavaScript line to validate your forms
#63Earlier quoted context omitted.
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.
They'll come don't worry ;)
Alright. Give us an example of how to make them and I'll fork, patch, and pull request.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#64This 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 plug…
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 thro…
To fix that, you can do a DNS lookup and check the domain has a valid MX record.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#65Has 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 inv…
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.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#66Has 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 inv…
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
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.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#67This 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 plug…
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…
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.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#68Earlier quoted context omitted.
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 thro…
To fix that, you can do a DNS lookup and check the domain has a valid MX record.
Just be careful when you do this. If you don't use an absolute FQDN you can trigger severe delay in getting a response from the resolver. It can take twenty or thirty seconds (or more) to get a response.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#69"DOM-API" is redundant, as the DOM is an API.
Re: Parsley.js: never write a single JavaScript line to validate your forms
#70Earlier quoted context omitted.
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…
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 re…
Nobody thinks a regular expression will prevent someone from signing up with an email that doesn't exist.
If you absolutely must have valid email addresses the only sure way is to make them confirm it with information from an email sent to the address.