I'm submitting a...
[ ] Regression
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
Current Behavior
@Query()
decorator is working perfectly in most cases but when we need to cast the value of the query to Number
, Boolean
or Array
types we must write code for that over and over again. I think we can develop some reusable decorators for that.
Suggested Method
Additional @Query()
decorators.
BooleanQuery(param?: string)
NumericQuery(param?: string)
ArrayQuery(param?: string, separator?: string)
If this is ok for NestJs project, I can contribute :)
Thank you.
I like the idea of having the @Query()
decorator type-aware! So far I tackled this problem by using a pipe that checks and transforms the query parameter into the desired type.
Personally, I think it would be great to have such a feature in the framework.
To complement this feature when using @Query()
with an object, something like:
@Query() foo:Bar
export class Bar {
foo: string;
bar: number;
}
maybe if we use class-transformer
to do that would be great too and turn this in something like
export class Bar {
@Type(() => String)
foo: string;
@Type(() => Number)
bar:number;
}
I had a similar issue if @Query()
because don't parse values and now i'm using plainToClass
function from class-transformer
I don't think we should add more decorators (to don't confuse new users and don't overcomplicate the basic features). However, we should automatically cast @Query('PROPERTY_NAME')
and @Param('PROPERTY_NAME')
to inferred types (either boolean
or number
) when the transform
in the ValidationPipe
is set to true
(https://docs.nestjs.com/techniques/validation#transform-payload-objects). Since this is a breaking change, it will be added in the next major release (7.0.0) - PR is merged already https://github.com/nestjs/nest/pull/4110. In addition, we should add ParseBoolPipe
and ParseArrayPipe
to cover other scenarios (parsing array or explicitly parsing boolean values) - this PR is merged as well https://github.com/nestjs/nest/pull/4113 (and will be published as part of 7.0.0 release).
Ah, very nice! I didn't see that these PRs already exist. I think with these transforming pipes (and even some more) it will be a lot easier to work with proper types for (query-) parameters.
Really like this solution and I'm looking forward to 7.0.0 then 馃憤
Most helpful comment
I like the idea of having the
@Query()
decorator type-aware! So far I tackled this problem by using a pipe that checks and transforms the query parameter into the desired type.Personally, I think it would be great to have such a feature in the framework.