generated from chevere/package-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
When validating email using regex you end up with a fairly short regex:
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
(Yes, this is the short version)
The actual problem here is that when it fails to validate the message will be very hard to understand as it will read:
[email]: Value provided "xyz" doesn't match the HUGE_REGEX_USERS_WONT_UNDERSTAND hahahah
Which I believe it beats the purpose of passing messages to the end user.
We need something more friendly, being able to label the "thing" we are validating:
$string->withMessage('Value provided `%value%` is not a valid email address');With this the message could be:
[email]: Value provided "xyz" is not a valid email address
This could allow spawning several pseudo-types:
function email(...) {
return $string->withMessage(...);
}Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels