페이징 적용, 장소 카테고리 추가 #74
Conversation
등록 DTO 검증 조건 수정
| @Query('page') page?: number, | ||
| @Query('limit') limit?: number, | ||
| ) { | ||
| if (isNaN(page)) page = 1; // Todo. number 타입 선택적 매개변수일 때 NaN 으로 처리되어 추가. 다른 방법? |
There was a problem hiding this comment.
q: 아래와 같은 방법으로는 안 걸러질까요?
const pageNumber = page ?? 1;
const limitNumber = limit ?? 10;There was a problem hiding this comment.
?? 키워드가 undefined, null 을 처리해주는데,
number타입인 페이지와 리미트 인자가 들어오지 않았을 때 NaN 으로 매핑되더라구요..
저도 이 부분 마음에 들지 않아 Todo 로 남겨두었습니다 ㅎㅎ;;
There was a problem hiding this comment.
p2: page를 적어두지 않았으면 보통 1페이지일테니 page: number = 1로 하는건 어떨가요?
There was a problem hiding this comment.
재밌는걸 찾았는데, 따끈따끈한 이슈인가봐요!
ValidationPipe 의 transform 옵션이 문제를 일으키고 있다고 해요.
nestjs/nest#12864 ( 기본값 두었을 때 문제 )
nestjs/nest#10246
11.0.0 버전에 수정될 예정이라고 합니다 ㅎㅎ
nestjs/nest#12893
이건 개발 일지에 남겨도 좋겠네요
| thumbnailUrl?: string; | ||
|
|
||
| @IsNumber() | ||
| @Min(0) | ||
| @Max(5) |
There was a problem hiding this comment.
p2.5: 별점같은 경우는 DB에서 5점만점이라도 소수점을 지원할 경우, 0부터 10의 정수로 저장하는 경우를 봤었는데요! gpt는 정수형 저장이 평균계산 등에서 성능적으로 좋다고는 하는데, 확인해보셔도 좋을 것 같네요 😀
There was a problem hiding this comment.
해당 필드는 구글에서 가져온 4.33 형태의 값인 평점입니다!
말씀하신 부분이 성능상의 유의미한 차이를 만들게 된다면,
우리 서비스에서 평점의 정확도가 가지는 가치와 비교해 보고 결정하면 될 것 같아요!
정확도가 중요하지 않다고 판단되었을 때, 4.33 이면 9로 저장한다던지?
저는 개인적으로 그럴거면 저장하지 않는 것이 나을 수도 있다고 생각합니다!
아마 말씀해주신 부분은 개인 리뷰에 달린
4 , 4.5형태의 값인 별점에 대한 이야기 아닐까요? ㅎㅎ
There was a problem hiding this comment.
아하 ! 제가 착각했네요 하하
저의 경우는 0.5 단위로 리뷰를 제공하는 케이스에만 적용됩니다.
소수점 둘째자리까지 표기해야한다면 정확도가 더 중요할 것 같아요.
| @Query('page') page?: number, | ||
| @Query('limit') limit?: number, | ||
| ) { | ||
| if (isNaN(page)) page = 1; // Todo. number 타입 선택적 매개변수일 때 NaN 으로 처리되어 추가. 다른 방법? |
There was a problem hiding this comment.
p2: page를 적어두지 않았으면 보통 1페이지일테니 page: number = 1로 하는건 어떨가요?
| @@ -0,0 +1,37 @@ | |||
| import { Place } from '../entity/place.entity'; | |||
|
|
|||
| export class PlaceSearchResponse { | |||
There was a problem hiding this comment.
q: PlaceListResponse 와 내용이 같은 것 같은데 구분한 이유가 있나요?
There was a problem hiding this comment.
변경 전에 장소나 코스의 리스트로 담아 보내는
PlaceListResponse 가 임시로 PlaceResponse 이름을 쓰고 있었고,
검색 API 에서는이 DTO 대신 엔티티 자체가 응답되고 있었어요!
장소 특성상 문제가 생기지 않았지만,
지도나 코스의 경우
즉시 로딩하는 지도_장소 와 순환 참조 문제가 생겨
jsonignore 같은 별도의 설정을 해 주어야 해요.
서로 다른 API 에서 같은 DTO 를 사용하다 보면,
한 쪽에만 변경이 있을 때에 유연하게 대처할 수 없다고 생각해,
응답 DTO를 용도별로 분리하는 편입니다!
There was a problem hiding this comment.
검색 API 에서는이 DTO 대신 엔티티 자체가 응답되고 있었어요!
헉 그러네요 제 실수..
서로 다른 API 에서 같은 DTO 를 사용하다 보면,
한 쪽에만 변경이 있을 때에 유연하게 대처할 수 없다고 생각해,
응답 DTO를 용도별로 분리하는 편입니다!
좋습니다!
📄 Summary
🙋🏻 More
🕰️ Actual Time of Completion
close #69
close #73