arb / celebrate

A joi validation middleware for Express.
MIT License
1.34k stars 65 forks source link

Feature request: more errors options #196

Closed dn-l closed 4 years ago

dn-l commented 4 years ago

Hi there! Would be really neat to have more errors middleware options to give some flexibility:

  1. message string|false| undefined|null| Currently it is "celebrate request validation failed" which I'd like to omit
  2. Error string|false|undefined|null Same purpose. For example, error: 'Bad Request: validation failed'
  3. mapped boolean Will do map to field names. This is the current response: Screen Shot 2020-09-13 at 11 32 58

    Which is not really usable on the UI side. With mapped it would look like this:

    Screen Shot 2020-09-13 at 11 31 13

Here's the code (not sure if path.join('.') is the best solution tho):

function formatCelebrateErrors (err) {
  const result = {}
  for (const [key, { details }] of err.details) {
    result[key] = details.reduce((acc, { path, message }) => {
      acc[path.join('.')] = {
        message
      }
      return acc
    }, {})
  }
  return result
}
  1. Validation details field name -- to change validation to something different, for example details

Tell me what do you think?

arb commented 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.

dn-l commented 4 years ago

Gotya. Yea that's exactly what I did in my case.