Closed dn-l closed 4 years ago
This would be a very large amount of customization to expose to the errors
API. Have you looked into writing your own errors middleware for handling celebrate errors and checking the incoming error with isCelebrateError
? My concern is this is very specific to your use case. I wouldn't want to expand the errors
AP surface area to help a single request.
Additionally, the errors from Joi and celebrate are generally not intended to be sent directly back to the user. Often times they contain way more information than the user needs or should see.
Gotya. Yea that's exactly what I did in my case.
Hi there! Would be really neat to have more
errors
middleware options to give some flexibility:string|false| undefined|null|
Currently it is "celebrate request validation failed" which I'd like to omitstring|false|undefined|null
Same purpose. For example,error: 'Bad Request: validation failed'
boolean
Will do map to field names. This is the current response:Which is not really usable on the UI side. With mapped it would look like this:
Here's the code (not sure if
path.join('.')
is the best solution tho):validation
to something different, for exampledetails
Tell me what do you think?