Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's also easily misused. Take the regular expression validator for passwords on the California DMV website, for example. The website states "Must include at least 4 alpha characters". But the validation pattern

    ^(?=(.*[a-zA-Z]){4,})(?=.*[0-9!#$%]).+$
requires that these characters appear consecutively.


The {4} is being applied to the whole group which includes a .*

Isn't that correct?


Yep, and the .* means "0 or more of anything", so it's 4 or more groups that each end with a letter. They can be consecutive or not and a group can be a single letter but doesn't need to be - so whatever the failure was, it wasn't that (or the regex was typo'd here to be correct instead of what was actually on the site).


The regexp still requires four letters before the last digit or special character which is a weird requirement.


The (?=…) are "lookaheads". They match the enclosed pattern without advancing the cursor.


That's exactly the case where the "customValidity" attribute shines!

I have nothing against regex and the "pattern" attribute is the way to go for many cases, but having this is an alternative is also very nice:

const valid = value.length => 4 && isAlphanumeric(value); return ( <Input value={value} customValidity={valid ? 'at least 4 alpha characters' : ''} /> )


AFAIK customValidity is not an attribute and you can only use an imperative setCustomValidity API which is terrible cumbersome to use in a declarative framework like React.


Yeah this is exactly what I'm writing about in the article :)


Yeah well I promise it does read nicely when there's formatting which HN comments do not allow :)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: