Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the reuse of @ApiResponse decorators (and decorators derived from those) for a single handler/class #2819

Open
1 task done
StiliyanKushev opened this issue Feb 5, 2024 · 0 comments
Labels

Comments

@StiliyanKushev
Copy link

StiliyanKushev commented Feb 5, 2024

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Take the following example:

  @ApiCreatedResponse({ description: 'successful user registration' })
  @ApiConflictResponse({ description: 'user already exists' })
  @ApiBadRequestResponse({ description: 'email is invalid' })
  @ApiBadRequestResponse({ description: 'password is too short' })
  @ApiBadRequestResponse({ description: 'dto is invalid' })
  @Post('sign-up')
  signUp(@Body() signUpDto: SignUpDto) {
    return this.authService.signUp(signUpDto);
  }

Under ideal circumstances, I'd love to be able to use the above code to describe different scenarios that ultimately all lead to the same http error response code.

Instead we have to do something like this for example:

  @ApiCreatedResponse({ description: 'successful user registration' })
  @ApiConflictResponse({ description: 'user already exists' })
  @ApiBadRequestResponse({
    description: [
      'dto is invalid',
      'password is too short',
      'email is invalid',
    ].join(' or '),
  })
  @Post('sign-up')
  signUp(@Body() signUpDto: SignUpDto) {
    return this.authService.signUp(signUpDto);
  }

or implement our own decorator wrapper (which IMHO helps bloat the project with misc utilities).

Describe the solution you'd like

As mentioned above, I'd love to see reuse of decorators being supported.

Teachability, documentation, adoption, migration strategy

I believe this to be a rather trivial feature to implement, and IMHO it improves the quality of the code and makes it a tad bit more readable.

What is the motivation / use case for changing the behavior?

Basically, just code readability. Let me know if this is something others might also appreciate, and I'd be glad to make a PR with my take on it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant