Conversation
|
|
||
| // TODO 5. return | ||
| return new GetSpaceJoinDto.Response( | ||
| getSpaceJoinDto.getSpaceProfileImg(), |
There was a problem hiding this comment.
p2: spaceBySpaceId.getSpaceProfileImg()를 바로 넘기지 않고 dto로 한 번 래핑하신 이유가 있을까요??
There was a problem hiding this comment.
Space 엔티티의 필드로부터 스페이스 이름, 썸네일 url, LocalDateTime 형태의 스페이스 생성일 이렇게 3개의 정보를 얻을 수 있는데, response를 구성하기 위해서는 추가적으로 스페이스 가입 멤버 수가 필요하고 또한 스페이스 생성일을 format 처리도 필요해서 dto의 필드와 dto 내부 Response 클래스의 필드를 구분하였습니다!!
따라서 Space 엔티티에서 얻은 spaceProfileImg 정보를 dto의 필드값으로 가지고 있는 상태여서, return 타입을 구성할 때 dto의 spaceProfileImg 를 사용하였습니다
| Space spaceBySpaceId = spaceDao.findSpaceBySpaceId(spaceId); | ||
|
|
||
| // 해당 유저가 스페이스에 가입되어 있는지를 확인 | ||
| Optional<UserSpace> userSpaceByUserAndSpace = userSpaceDao.findUserSpaceByUserAndSpace(userByUserId, spaceBySpaceId); |
There was a problem hiding this comment.
p3: UserSpaceUtils의 isUserInSpace 메소드를 활용할 수 있을 것 같아요
There was a problem hiding this comment.
UserSpaceUtils의 isUserInSpace 메서드는 해당 유저가 스페이스에 속해있지 않을 경우 예외를 발생시키지만, 해당 스페이스 가입 view api 플로우에서는 유저가 스페이스에 이미 가입되어 있는 경우 예외를 발생시키는 것이 맞다고 판단해서 UserSpaceUtils에 새로운 메서드를 생성하여 코드를 구성하였습니다!!
오 프론트분들과 api 연동작업하면서 한번 논의할 필요는 있을거같네요! 의견 감사합니당 |
| private String spaceProfileImg; | ||
|
|
||
| private String spaceName; | ||
|
|
||
| private LocalDateTime createdAt; |
There was a problem hiding this comment.
아래 static class Response 와 중복되는 필드를 갖는데 어떤 의미인지 궁금합니다
There was a problem hiding this comment.
Space 엔티티의 필드로부터 스페이스 이름, 썸네일 url, LocalDateTime 형태의 스페이스 생성일 이렇게 3개의 정보를 얻을 수 있는데, response를 구성하기 위해서는 추가적으로 스페이스 가입 멤버 수가 필요하고 또한 스페이스 생성일을 format 처리도 필요해서 dto의 필드와 dto 내부 Response 클래스의 필드를 구분하였습니다!!
📝 요약
스페이스 가입 view 를 위한 데이터를 response에 담아 보내주는 api 개발
이슈 번호 : #67
🔖 변경 사항
jwt에 담긴 userId와 pathVariable 로 얻을 수 있는 spaceId로 해당 유저가 이미 스페이스에 가입되어 있는 유저인지를 검증하기 위한 코드를 컨트롤러단에 구성하였습니다.
현재는 이미 스페이스에 가입된 유저일 경우, 기존의 exception 과 동일하게 500 에러가 response로 전송됩니다
상준님이 개발하신 exception handler가 develop 브랜치에 머지되면, 이슈 생성 후 예외처리의 리펙토링을 진행하겠습니다
✅ 리뷰 요구사항
유저가 이미 스페이스에 가입되어 있는 경우, 예외처리를 통해 response로 4xx 예외를 보내는 방법과 response 에 해당 유저가 스페이스에 가입되어 있는 지의 여부를 나타내는 필드를 추가하는 방법 중 전자가 낫다는 판단하에 개발을 진행하였습니다.
컨트롤러 단에서 검증 로직을 통해 유저가 이미 스페이스에 가입되어 있는 경우, 굳이 스페이스 가입 view 를 위해 db 를 방문하여 데이터를 얻어오는 후작업을 할 필요가 없다고 판단했기 때문입니다.
혹시 다른 의견 있으시면 리뷰 남겨주세요!!
📸 확인 방법 (선택)
postman을 이용하여 유저가 스페이스에 가입되어 있지 않은 경우, 이미 가입된 경우의 결과를 확인하였습니다
리펙토링 시에 테스트 코드를 추가해보겠습니다
📌 PR 진행 시 이러한 점들을 참고해 주세요