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

make transforming DTO property names easier. Clarify docs. #2473

Open
1 task done
fauxbytes opened this issue Sep 28, 2022 · 1 comment
Open
1 task done

make transforming DTO property names easier. Clarify docs. #2473

fauxbytes opened this issue Sep 28, 2022 · 1 comment

Comments

@fauxbytes
Copy link

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

The use-case I am thinking-of is exposing properties in request DTOs with names independent of the underlying property. Often, naming conventions differ: e.g. DTOs are coded with camel case:

export class FooDTO {
    string barName: string;
}

, but the api exposes snake case params:

curl -X 'POST' \
  'http://localhost:3000/foo' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "bar_name": "string",
}'

Decorating every propery with @Expose allows the above request to push through:

export class FooDTO {
  @Expose({name: 'bar_name'})
    string barName: string;
}

however, this transformation isn't picked-up by the swagger module, leading to an incorrecrt api desc.
further massaging the api with @ApiProperty yields a partial relief:

export class FooDTO {
  @Expose({name: 'bar_name'})
  @ApiProperty({name: 'bar_name'})
    string barName: string;
}

Now, the transform is refected in the api desc. However, in error messages (e.g validation errors), it is the original symbol that gets embedded in the message.

Describe the solution you'd like

Would be good if such a transformation could be achieved with less boilerplate. But primarily, think uses will benefit from a clear documentation of this recipe (perhaps add it to one of the samples?).

Teachability, documentation, adoption, migration strategy

n/a

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

It's a common use-case IMO, so docs would save time.

@Dosenbiiir
Copy link

Dosenbiiir commented Sep 20, 2024

Any news on this? An improvement would be nice. Or is there any other way to write a custom transformation for the documentation? I have an Interceptor transforming all responses to snake_case automatically. But the generated documentation has camelCase properties.

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

No branches or pull requests

2 participants