`TypedParam` does not support object destructuring without name parameter like NestJS Param

[AprilNEA]

Description

In NestJS, it's possible to use the @Param() decorator without specifying a name to get an object containing all route parameters:

@Get('recent/:param1/:param2')
findRecent(@Param() params: FindRecentPostDto) {
  const { param1, param2 } = params;
  return ;
}

However, Nestia's TypedParam does not seem to support this functionality. It requires specifying a name parameter to extract a specific route parameter.

Expected Behavior

TypedParam should be able to be used without a name parameter to retrieve an object containing all route parameters, similar to NestJS's @Param() decorator.

Current Behavior

TypedParam requires a name parameter to be specified and only retrieves a single route parameter value.

Proposed Solution

Enhance TypedParam to support object destructuring when used without a name parameter, maintaining consistency with NestJS's @Param() decorator behavior.

Additional Context

This feature would improve the compatibility between Nestia and existing NestJS codebases, making it easier for developers to migrate or use Nestia in their NestJS projects without significant changes to their parameter handling logic.

Code Example

// Desired usage (currently not supported)
findRecent(@TypedParam() params: FindRecentPostDto) {
}

Question

Is this a planned feature for Nestia? If not, would it be considered for implementation to improve compatibility with NestJS?

[samchon]

No plan to support this feature for safety reason.

[rivatove]

No plan to support this feature for safety reason.

May I know what safety reasons you are referring to? How are DTO classes unsafe to be used as parameter containers?

Also, I saw you mention on the NestJS Discord server that nestia can be used only for Swagger/SDK generation. That is currently not possible if the project utilizes the @Param decorator with a DTO. I'm encountering the following error: @Param() must have a field name.

[samchon]

If allows keyworded propertised object type, the path parameters can be easily optional.

By the way, following the OpenAPI specs, the path parameters are always required and it is not categorized in the keyworded parameters, but positional parameters. This is why I am blocking it.

Type safe OpenAPI document composition and this issue feature cannot be compatible.