You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently the ValidationFailedError class only provides access to the error details through the errors class attribute but this errors attribute is just an array of strings and its impossible to separate out the argument name and the error description without doing some regex on that those strings.
It is often useful to have the argument name separated out from the error description because API consumers need to know which argument had issues in a programmatic way.
This is what consumers of an API would receive today
Provide the argument name and description as separate class attributes on the ValidationFailledError class. I don't really care if it gets included in the "extensions" property as demonstrated above but including those attributes allows users of this library to include them in the extensions if they want to by using rescue_from and including the additional details.
Describe alternatives you've considered
The only alternative to adding this feature I believe is to parse out the argument name and description manually with regex. i.e.
if the error is "lastName can't be blank" then you would need to parse out "lastName" and "can't be blank" into separate variables.
Additional context
I would be happy to work on this feature if the library authors agree this is something they want to add. I believe this can be done in a non breaking way by leaving the current ValidationFailedError.errors class attribute the way it is and providing an additional attribute error_details or something similar that includes an array of hashes. error_details: [{ name: "lastName", description: "can't be blank" }]
The text was updated successfully, but these errors were encountered:
👍 Thanks for the suggestion, I agree that your proposed fix would be a nice improvement. You might have to add a new parameter to Validator.validate! to accept the argument definition so that you could get the name from it. Please give it a try and let me know if I can help along the way!
Is your feature request related to a problem? Please describe.
Currently the ValidationFailedError class only provides access to the error details through the
errors
class attribute but this errors attribute is just an array of strings and its impossible to separate out the argument name and the error description without doing some regex on that those strings.It is often useful to have the argument name separated out from the error description because API consumers need to know which argument had issues in a programmatic way.
This is what consumers of an API would receive today
This is what I believe API consumers should receive
Describe the solution you'd like
Provide the argument name and description as separate class attributes on the ValidationFailledError class. I don't really care if it gets included in the "extensions" property as demonstrated above but including those attributes allows users of this library to include them in the extensions if they want to by using
rescue_from
and including the additional details.Describe alternatives you've considered
The only alternative to adding this feature I believe is to parse out the argument name and description manually with regex. i.e.
if the error is "lastName can't be blank" then you would need to parse out "lastName" and "can't be blank" into separate variables.
Additional context
I would be happy to work on this feature if the library authors agree this is something they want to add. I believe this can be done in a non breaking way by leaving the current ValidationFailedError.errors class attribute the way it is and providing an additional attribute
error_details
or something similar that includes an array of hashes.error_details: [{ name: "lastName", description: "can't be blank" }]
The text was updated successfully, but these errors were encountered: