-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor: #310 MSW 처리중 userServiceHandler 기능 리팩토링 #314
Conversation
Walkthrough이 풀 리퀘스트는 사용자 프로필 관리와 관련된 목업(mock) 서비스 핸들러의 리팩토링에 중점을 둡니다. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/mocks/services/userServiceHandler.ts (2)
67-68
: **토큰 검증 로직 반복 **
동일한 로직이 반복 적용되어 있지만, 모킹 시나리오 상 중복이 불가피해 보입니다. 실제 코드베이스에서는 공통화도 고려해볼 수 있습니다.
96-96
: **userId 유효성 추가 확인 **
코드 유지보수 측면에서 동일 로직이 반복되지만, 목업 구조 상 이중 확인이 불가피한 점은 이해됩니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/mocks/mockAPI.ts
(6 hunks)src/mocks/mockData.ts
(2 hunks)src/mocks/mockHash.ts
(0 hunks)src/mocks/services/teamServiceHandler.ts
(3 hunks)src/mocks/services/userServiceHandler.ts
(3 hunks)src/types/MockType.tsx
(1 hunks)
💤 Files with no reviewable changes (1)
- src/mocks/mockHash.ts
🔇 Additional comments (48)
src/mocks/services/userServiceHandler.ts (30)
2-2
: **USER_DUMMY 임포트 확인 **
USER_DUMMY
가 아래 검색 로직(라인 216 이후)에서 정상적으로 사용되고 있어 불필요한 임포트가 아니며, 정상 동작을 위한 의존성으로 보입니다.
3-15
: **모듈화된 API 함수 임포트 **
@mocks/mockAPI
에서 다양한 유저 관리 함수를 임포트해 잘 분리된 구조로 보입니다. 코드 유지보수성 향상에 도움이 됩니다.
19-19
: **타입 임포트 **
EditUserInfoForm
및 EditUserLinksForm
타입을 명시적으로 임포트하여 TS의 이점을 잘 살리고 있습니다.
27-27
: **request.json() 처리 **
요청 바디를 await request.json()
으로 파싱 후, EditUserInfoForm
으로 지정해 타입 안정성을 확보한 점이 적절합니다.
30-30
: **토큰 검증 로직 **
if (!accessToken)
분기를 통해 인증 로직을 명확히 처리하고 있습니다. 401 코드 반환도 일관성이 있습니다.
34-34
: **userId 검증 로직 **
토큰에서 userId가 없을 경우 에러 처리를 명시적으로 해주어, 잘못된 토큰에 대한 방어 코드가 확실합니다.
36-39
: **닉네임 검증 **
정규식을 통해 닉네임 포맷을 검사하고 있으며, 부적합 시 400 에러를 반환하여 클라이언트에 원인을 명확히 전달하고 있습니다.
42-47
: **updateUserInfo 예외 처리 **
try
블록에서 update 함수를 호출하고, 에러 발생 시 적절한 메시지로 401을 반환하여 에러 전파 흐름이 일관됩니다.
50-57
: **변경된 유저 정보 반환 처리 **
DB(더미)에서 변경 정보를 다시 조회 후 반환함으로써, 업데이트 직후의 정확한 상태를 응답으로 보장합니다.
61-61
: **구분 주석 및 섹션 분리 **
API를 구분하는 주석이 가독성을 높입니다.
65-65
: **updatedUserLinks 타입 **
요청 바디를 EditUserLinksForm
로 파싱하여 TS 타입 안전성을 유지하고 있습니다.
70-70
: **userId 재확인 **
userId가 존재하지 않을 경우 에러를 즉시 반환함으로써, 올바르지 않은 요청 흐름을 빠르게 차단합니다.
Also applies to: 72-73
74-79
: **updateUserLinks 예외 처리 **
에러 발생 시 메시지를 반환하는 흐름이 일관적입니다. 401을 반환하는 로직 역시 통일감이 있어 유지보수에 좋습니다.
91-92
: **파일 업로드 전 토큰 체크 **
프로필 이미지 업로드 시에도 토큰이 유효한지 먼저 확인하여 보안 및 무결성을 확보합니다.
94-94
: **userId 검증 **
파일 업로드에서도 userId가 없으면 401을 반환합니다. 통일된 로직으로 일관성을 유지합니다.
98-100
: **업로드 파일 여부 및 타입 체크 **
파일 검증이 철저해 오류 상황(파일 미첨부, 파일 아님)을 명확히 구분 처리하고 있습니다.
102-115
: **프로필 업데이트 & 임시 저장 로직 **
updateUserProfile
후 로컬 Blob 데이터(saveUserProfileFileInMemory
)를 관리해 프로필 데이터와 파일이 분리된 구조가 명확합니다.
121-121
: **프로필 이미지 조회 API 등록 **
URL 패턴과 라우팅 적용이 명확하며, 실제 UI 관점에서도 직관적인 경로(file/profile/:fileName
)입니다.
124-125
: **토큰 검증 **
일관된 401 처리를 통해 인증/인가 시스템 흐름을 지속적으로 유지합니다.
127-127
: **userId 검증 **
파일 접근에 대한 userId 정보가 없으면 즉시 401 반환으로 접근 제한을 처리합니다.
Also applies to: 129-129
131-137
: **파일 조회 및 권한 체크 **
업로드명으로 파일을 찾고, userId가 불일치 시 403을 반환하는 로직이 적절합니다. 잘못된 접근 시나리오까지 처리해 보안성이 높습니다.
151-157
: **프로필 삭제 API 토큰 검증 **
삭제 작업 전 인증을 철저히 확인해, 불필요한 파일 삭제를 방지합니다.
158-164
: **파일/프로필 삭제 로직 **
deleteUserProfile
와 deleteProfileFileInMemory
를 함께 호출해 DB(가상)와 메모리 정보를 동기화하고 있습니다.
174-175
: **전체 팀 목록 조회 시 토큰 검증 **
동일한 패턴으로 유효성 검사를 적용하며, 일관성 있는 에러 처리를 보여줍니다.
177-177
: **userId 검증 후 진행 **
convertTokenToUserId
가 실패할 경우 빠르게 return 처리하는 점이 코드 가독성을 높입니다.
Also applies to: 179-179
182-182
: **팀 유저 목록 호출 **
findAllTeamUsersByUserId
를 호출해 팀 정보를 가져옵니다. 함수 명이 용도에 충실하여 가독성이 좋습니다.
184-184
: **teamJoinStatusList 맵핑 **
팀 가입 상태 정보를 맵핑하며, 데이터 구조가 명확하게 정리되어 있습니다.
186-193
: **역할/팀/유저 유효성 검사 **
각각의 find 함수를 통해 존재 유무를 검증 후 적절한 에러를 반환하고 있어, 에지 케이스를 꼼꼼히 고려한 모습입니다.
199-199
: **creator 필드 매핑 **
팀장의 닉네임을 포함해 반환함으로써, 클라이언트에서 표시에 필요한 데이터를 명확히 전달합니다.
216-216
: **유저 검색 시 사전 토큰 검증 **
검색 처리에서도 토큰 검증 후 userId를 추출하여, 쿼리 동작에 대한 보안성을 확보하고 있습니다.
Also applies to: 220-220
src/mocks/mockAPI.ts (12)
3-3
: **PROFILE_IMAGE_DUMMY 임포트 **
프로필 이미지 관리를 위해 PROFILE_IMAGE_DUMMY
를 가져오며, 관련 로직이 이 파일에서 일관되게 처리됩니다.
17-17
: **유저 관련 타입 추가 임포트 **
EditUserInfoForm
, EditUserLinksForm
, User
등의 타입을 명시적으로 가져옴으로써 TS의 강점을 살렸습니다.
22-29
: **새로운 타입(ProfileFileForMemory 등) 임포트 **
프로필 이미지, 태스크 파일 등 새로운 타입을 통합 관리하여 데이터 구조를 명확하게 정의하고 있습니다.
48-56
: **updateUserInfo 함수 추가 **
유저가 존재하지 않을 경우 에러를 던지고, 닉네임과 bio만 수정하는 로직이 간결하며, 예외 처리가 적절합니다.
58-63
: **updateUserLinks 함수 추가 **
링크 수정 시도 시 유저 미존재 여부를 먼저 확인해 에러를 던지는 점이 안전하며, 업데이트 로직이 명확합니다.
65-70
: **updateUserProfile 함수 추가 **
유저 프로필 파일명을 업데이트하고 존재하지 않을 시 에러를 던져, 예외 처리를 간결하고 분명하게 합니다.
72-77
: **deleteUserProfile 함수 **
유저 프로필 삭제 시 fileName을 null로 세팅, 유저가 없으면 에러를 던져 404 상황을 적절히 처리합니다.
89-93
: **findAllTeamUsersByUserId 함수 추가 **
특정 유저가 속한 모든 팀User를 필터링하며, 역할별/팀별 로직 확장을 위해 명확히 분리된 함수가 인상적입니다.
217-217
: **프로젝트 관련 처리 주석 **
이 라인은 주석 섹션의 시작을 표시하는 것으로, 별도 리뷰가 필요 없어 보입니다.
441-449
: **saveUserProfileFileInMemory 함수 **
유저마다 프로필 파일 메모리를 확인하고, 기존 레코드가 있으면 업데이트, 없으면 새로 푸시하여 효율적입니다.
451-454
: **downloadProfileFileInMemory 함수 **
업로드 이름으로 파일을 단일 조회하며, 메모리 내 파일 구조 관리가 단순 명료합니다.
456-461
: **deleteProfileFileInMemory 함수 **
유저 ID를 사용해 바로 파일 레코드를 찾아 삭제하며, 에러 상황에 대한 명확한 예외 처리(throw
)를 수행 중입니다.
src/types/MockType.tsx (1)
32-37
: **ProfileFileForMemory 타입 추가 **
userId
, file
, uploadName
를 포함해 프로필 이미지를 메모리에 저장하기 위한 구조가 명확하게 정의되어 있습니다.
src/mocks/services/teamServiceHandler.ts (3)
22-22
: **findAllTeamUsersByTeamId 임포트 **
팀 단위로 유저 정보를 가져오는 함수로, 보다 명확해진 함수명(ByTeamId
)이 가독성을 높입니다.
57-57
: **findAllTeamUsersByTeamId 사용 **
이전 findAllTeamUsers
대신 팀 ID 기반으로 필터링하여, 로직 명료도와 확장성을 모두 높였습니다.
262-262
: **팀원 조회 API에서 findAllTeamUsersByTeamId 사용 **
팀원 정보를 가져올 때 팀 ID를 사용해 뚜렷하게 식별하며, 불필요한 데이터 스캔을 줄일 수 있습니다.
src/mocks/mockData.ts (2)
9-16
: **ProfileFileForMemory 타입 임포트 **
ImageInfo
대신 새 타입 ProfileFileForMemory
를 활용해, 프로필 이미지 관련 구조를 한층 명확하게 관리하고 있습니다.
816-816
: **PROFILE_IMAGE_DUMMY 배열 **
빈 배열로 초기화하여, 이후 로직(saveUserProfileFileInMemory
등)으로 동적으로 채워지는 구조가 유연하며, 목업 데이터 수정에 용이합니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
project , team msw 양이 많은데 user까지 고생 많으십니다..
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
유저 쪽도 같이 변경해주셨네요ㅠㅠㅠ 제 담당이었는데... 감사합니다!!
PR Type
What kind of change does this PR introduce?
Related Issues
What does this PR do?
ImageInfo
→ProfileFileForMemory
)