The Problem No One Talks About
Let's be real: email validation sounds simple, but it's a technical trap that catches even experienced de...
For further actions, you may consider blocking this person and/or reporting abuse
A really simple validator is to use the built-in field validation of the email input type.
If you plan to call it frequently you could persist the DOM element.
i really like this approach
Bug spotted: the "Basic Validation That Actually Works" example here will fail on
admin@mailserver1
which you previously recognised as valid.thanks, that's true for single label domain, have amended.
We use client side and server side validation without duplicating the code with trpc, zod and npm workspace as Zod is in a shared package. So it can be used by the client and the server
github.com/alan345/TER
In a browser, use input type="email"
It’s only a client-side validation that can be easily bypassed. Server-side validation always required.
that's the ideal case: a basic client-side validation coupled with a validation from the server side.
Of course, nobody argues about that )
Devs who don't understand regex or email validation may have this problem. Eitherway its handled on the backend anyway. Front end validation is just to save an api request and improve ui experience. Untested and yes problems arise. My tip: don't use 1 regex. Break it up to reduce complexity. Or keep it simple and forgiving. /[^@]+\@[^\@.]+(.[^\@]+)*/. Or better yet just use zod or yup.
Indeed, libraries are also written by ppl and might use the same techniques listed above. Typically, checking domain name to be valid is simple and enough to send confirmation letter (in most cases), everything else is on a user.
yes, definitely for the client-side validation.
HAHAHAHA i tried to make an account for this site
also, subgenius reference ;) i thought everyone had forgotten already
srsly though the email is 76 characters and once i tried to create an account and the form max length was 75 (removing the html limit worked lol)