Open omer-g opened 2 years ago
Hi @omer-g,
Thanks a lot for all your feedbacks recently. The issues you pointed out about #50 are also the issues that I was worried about. cc: @eden-omb.
Currently working with a newer solution that doesn't involve a bypass
of the name property.
What I did in my project was use validator.name
not as a name but rather as a key for an i18n. This way for an error with name between
I can have an i18n string errors.between: "{n} is not between {min} and {max}"
which I then transpile using the error name and specific values.
I also set it up so a form has a specific base i18n key for errors and the formatter looks there and falls back onto generic validation error strings, but that's a different story ;)
Is your feature request related to a problem? Please describe. Currently, it seems that there is no way to programmatically iterate over validation errors and print a custom error message for each. In the documentation, an
{#if}
statement is used to print errors one by one.It's possible for users to maintain an additional object that maps a validator's name to a custom error message, but that is rather cumbersome and "boilerplatey".
Describe the solution you'd like Add an optional
errorMessage
property to the object returned by the (inner) validation function inValidator
. The type of the property could be() => string | string
. This would allow one to programmatically generate custom error messages based on current input value at the time of validation (or static messages as well).Describe alternatives you've considered Provide a separate object that maps each validator name to an (optional) error message (which is of type
() => string | string
). This has the benefit of not requiring a change in the signature ofValidator
. An additional method could be included that iterates over current error messages. A drawback is that it relies on the user entering unique names to validators (not sure if that might already be the case?).Additional context There is currently a pull request (#50) by @eden-omb that relates to a similar issue. From what I understand, they suggest to use the
name
property to pass informative errors. This would be helpful but has three main issues:name
ofValidator
as a key in their own objects that need a string key. Validation error messages are not always unique, and it's probably preferable not to use error messages as keys.between(5, 10, "Must be between 5 and 10")
cannot have a message such as:4 is not between 5 and 10
.name
and not, for example,errorMessage
.