예전에 부트캠프에서 nestjs 관련 공부했을때 custom decorator를 만들어 본적이있다. 사실 그때 무작정 따라 치기 바빠서 이게 커스텀 데코레이터를 만드는건지도 몰랐는데 이번에 공부하면서 "응? 나이거 옛날에 해봤던거 같은데? 그때 했던 그게 커스텀 데코레이터 였구나..."라고 생각이 들었다.
커스텀 데코레이터
우선 커스텀 데코레이터를 왜 만드는지에 대해 생각해보았다. 사실 왜 만드는지 처음에는 이해가 안갔다. 이론적으로는 코드의 중복성이나 유지보수를 위해 만든다 라는 말들이 많았는데 커스텀 데코레이터를 만들면 왜 재사용성이나 유지보수에 좋은거지? 라고 이해가 가질않았다. 단적인 예시로 만약 request정보가 필요하다면 그냥 @Req() 를 쓰면 되는거 아닌가? 라고 생각 되기도 했었다. 그런데 생각해보면 @Req() 라는것은 nestjs에서만 사용이 가능한것이다. 그래서 만약 현재는 nestjs지만 환경을 옮겨 fasify나 다른 환경으로 마이그레이션시 간단하게 커스텀 데코레이터로 만들어두었던 것만 사용 환경에 맞게 고치면 될것이다. 이런 점에 있어서 유지보수와 재사용성이 높아진다고 한것같다.
그럼 이제 왜 사용하는지를 알았으니 어떻게 사용하는지 알아보자
우선 데코레이터들만 존재하는 폴더를 만들어 그곳에서 각 데코레이터를 만들어보기로했다.
common/decorator/user.decorator.ts
import { ExecutionContext, createParamDecorator } from '@nestjs/common';
export const User = createParamDecorator(
(data: unknown, ctx: ExecutionContext) => {
const request = ctx.switchToHttp().getRequest();
return request.user;
},
);nestjs는 커스텀 데코레이터를 만들수있는 createParamDecorator기능을 제공한다. 이것은 콜백을 인자로 받는데 첫번째 인자에 data 두번째 인자에 ctx(context)가 담기게 한다. 이제 request라는 변수를 만들어 그안에 http로 요청받은 요청 데이터를 담아준뒤 request를 리턴해준다.
이렇게 하면 기존에 아래와 같은 방식으로 user를 가져왔다면
Req() req{
return req.user
}이제는 그냥
@User() user{
return user
}만 해주면 되니 코드도 더 깔끔해진다. 위 예시를 보면 switchToHttp를 사용했지만 nestjs는 한서버 안에서 rtc, ws등을 지원하기 때문에 swtichToWs, switchToRtc등 여러 옵션이 있다.
재미는 있었는데 사실 아직도 내 머리속에서는 100% 이해가 간건 아닌거 같다. 누군가에게 설명을 해줄순 있겠지만 단적인 예시로 마이그레이션 했을때 코드 유지보수를 위한것이라면 애초에 커스텀 데코레이터를 만들때 선언했던 createParamDecorator자체를 사용 못하는것 아닌가..? 이건 nest에 내장된 기능일텐대? nest에서만 쓸수있지 다른 환경으로 넘어간다면 아예 다른 코드가 될거같은데... 라는 느낌이 있지만 그래도 로직 자체는 변경되는것이 아니니 필요한 옵션만 갈아끼면 유지보수가 되겠지 라고 생각은 하여 일단은 여기서 정리하되 또 다른 큰 깨달음이 오면 그때 다시 이 글로 돌아와 수정하도록 하겠다.
