DEV Community

Micael Levi L. C.
Micael Levi L. C.

Posted on • Updated on

NestJS tip: type safety on parameter decorators

for NestJS v8, v9 and v10

In NestJS we can create specialized kind of parameters decorators using the createParamDecorator function from @nestjs/common. For example:



import { createParamDecorator, ExecutionContext } from '@nestjs/common'

export const CurrentUser = createParamDecorator<
  keyof User | undefined, // the type of `data`
  ExecutionContext, // the type of `ctx`
>(
  (data, ctx) => {
    const request = ctx.switchToHttp().getRequest()
    const user = request.user
    return typeof data === 'undefined'
      ? user[data]
      : user
  }
)


Enter fullscreen mode Exit fullscreen mode

And then you can use that CurrentUser parameter decorator later in controller class's method, as follows:



// ...
@Get()
getCurrentUser(
@CurrentUser() user: User,
@CurrentUser('name') username: string,
) {
return { user, username }
}

Enter fullscreen mode Exit fullscreen mode




The issue

If your project has a bunch of those decorators, it might be hard to know what would be the type of their resolved values, right? I mean, how do you know that @CurrentUser() is a "bind" for request.user without some documentation or by reading the source? Also, what is the type of that request.user? Due to how TypeScript legacy decorators works, there's no way to typescript compiler infer some type from such param decorator.

My solution

You could see in my other article that I've leverage on TypeScript declaration merging feature like this:

basic demo

Along with generics, we can now easily couple the decorator with "its" type.

We just need to declare and export a type alias with the same name of our param decorator. See:



import { createParamDecorator, ExecutionContext } from '@nestjs/common'

export const CurrentUser = createParamDecorator<
keyof User | undefined, // the type of data
ExecutionContext, // the type of ctx
>(
(data, ctx) => {
const request = ctx.switchToHttp().getRequest()
const user = request.user
return typeof data === 'undefined'
? user[data]
: user
}
)

// -------- THIS IS NEW:
export type CurrentUser<Prop extends keyof User | undefined = undefined> =
Prop extends keyof User ? User[Prop] : User

Enter fullscreen mode Exit fullscreen mode


@Get()
getCurrentUser(
@CurrentUser() user: CurrentUser,
@CurrentUser('name') username: CurrentUser<'name'>
) {
return { user, username }
}

Enter fullscreen mode Exit fullscreen mode




Advantages

The ones I've seen so far:

  1. No one needs to recall what is the expected type of the resolved value by those parameters decorators. Just use the same name of the decorator.
  2. One source of truth of the expected type of such param decorator. If we change the implementation of that decorator in the future (and also the type of the returned object), we won't have to touch other parts of our codebase (unless we got some breaking change, of course).
  3. No need to import multiple types just for the sake of type safety.

Disadvantages

The ones I've seen so far:

  1. I didn't see this pattern often in the wild, so I won't expect it to be intuitive.
  2. If you use some pipe like this: @CurrentUser(MyPipe) somethingElse: any, that somethingElse parameter might not have the CurrentUser type anymore. So this pattern is restrict to those decorators that are not meant to use with pipes.
  3. User type is clear than CurrentUser one if you are familiar with User entity already. Thus, by reading the code outside of some code editor, it migth be a bit hard to find what that CurrentUser mean. But I think that this is just a matter of getting used of.

Top comments (4)

Collapse
 
kostyatretyak profile image
Костя Третяк

Maybe I didn't catch the essence of the issue, but it seems to me that the following code does the same thing as suggested in the summary, but simpler and more readable:

// ...
@Get()
getCurrentUser(
  @CurrentUser() user: User,
  @CurrentUser('name') username: User['name'],
) {
  return { user, username }
}
Enter fullscreen mode Exit fullscreen mode

As you can see, username is typed by User['name'].

Collapse
 
micalevisk profile image
Micael Levi L. C.

here's an example of a real world use case for such pattern that I've been using so far at work:

sample

that @Authorize() is a decorator made for that project. To me, it would be less easy for newcomers to know what is the type of authorize parameter. Now they just have to use the same name as the decorator factory being used ^^

Collapse
 
micalevisk profile image
Micael Levi L. C.

yep

The essence is that you have to know that @CurrentUser() resolves to User, in first place. Imagine have a tons of those decorators out there.

Collapse
 
kostyatretyak profile image
Костя Третяк • Edited

If there is a need for a large number of decorators for parameters, most likely you need to move parameter handling to HTTP interceptors.

In good frameworks (if you know what I mean ;) in route methods you can get parameter values by tokens, exactly the same as it is done in constructors:

// ...
@route('GET', '', [AuthGuard])
getCurrentUser(
  user: User,
  @inject(QUERY_STRING) queryString?: string,
) {
  return { user, queryString }
}
Enter fullscreen mode Exit fullscreen mode