Refactor: #196 MSW중 TaskService 관련 기능 리팩토링 #219
Conversation
Walkthrough이 변경 사항은 작업, 프로젝트, 사용자 및 역할과 관련된 엔티티를 관리하기 위한 포괄적인 모의 함수 및 타입 정의를 도입합니다. Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
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 (
|
|
@coderabbitai full review |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Outside diff range and nitpick comments (8)
src/types/MockType.tsx (5)
1-6: TeamUser 타입 정의가 잘 구조화되어 있습니다.TeamUser 타입은 팀 사용자에 대한 필요한 속성들을 잘 포함하고 있습니다.
isPendingApproval속성은 팀 가입 프로세스에 승인 단계가 있음을 시사합니다.가독성을 높이기 위해 각 속성에 간단한 주석을 추가하는 것을 고려해 보세요. 예를 들어:
export type TeamUser = { teamId: number; // 팀의 고유 식별자 userId: number; // 사용자의 고유 식별자 roleId: number; // 팀 내 사용자의 역할 식별자 isPendingApproval: boolean; // 사용자의 팀 가입 승인 대기 상태 };
8-12: ProjectUser 타입이 잘 정의되어 있습니다.ProjectUser 타입은 프로젝트와 관련된 사용자 정보를 적절히 표현하고 있습니다.
TeamUser 타입과의 일관성을 위해 다음과 같이 주석을 추가하는 것을 고려해 보세요:
export type ProjectUser = { projectId: number; // 프로젝트의 고유 식별자 userId: number; // 사용자의 고유 식별자 roleId: number; // 프로젝트 내 사용자의 역할 식별자 };또한, 프로젝트 참여에 대한 승인 프로세스가 있다면 TeamUser와 유사하게
isPendingApproval속성 추가를 고려해 볼 수 있습니다.
19-24: UploadTaskFile 타입이 잘 정의되어 있습니다.UploadTaskFile 타입은 작업에 업로드된 파일에 대한 정보를 적절히 표현하고 있습니다.
fileName과uploadName의 차이점을 명확히 하기 위해 주석을 추가하는 것이 좋겠습니다. 예를 들어:export type UploadTaskFile = { fileId: number; // 파일의 고유 식별자 taskId: number; // 연관된 작업의 고유 식별자 fileName: string; // 원본 파일 이름 uploadName: string; // 서버에 저장된 파일 이름 (중복 방지를 위해 변경될 수 있음) };이렇게 하면 두 속성의 용도가 더 명확해질 것입니다.
26-31: TaskFileForMemory 타입이 메모리 내 파일 처리를 위해 잘 정의되어 있습니다.이 타입은 작업과 관련된 파일을 메모리에서 처리하기 위한 구조를 잘 표현하고 있습니다.
타입의 용도를 명확히 하기 위해 다음과 같이 주석을 추가하는 것이 좋겠습니다:
export type TaskFileForMemory = { fileId: number; // 파일의 고유 식별자 taskId: number; // 연관된 작업의 고유 식별자 file: Blob; // 메모리에 저장된 파일 내용 uploadName: string; // 업로드될 파일 이름 };또한, 이 타입이 어떤 상황에서 사용되는지 (예: 파일 업로드 전 임시 저장, 미리보기 등) 간단히 설명하는 주석을 타입 정의 위에 추가하면 더 좋을 것 같습니다.
1-31: 전반적으로 잘 구조화된 타입 정의입니다.이 파일은 팀, 프로젝트, 작업 및 파일 업로드와 관련된 다양한 엔티티에 대해 잘 정의된 타입을 제공하고 있습니다. 이는 타입 안전성을 보장하고 개발자가 관련 기능을 구현할 때 명확한 가이드라인을 제공할 것입니다.
일관성을 위해 모든 타입에 대해 간단한 설명 주석을 추가하는 것이 좋겠습니다. 예를 들어:
/** 팀과 사용자 간의 관계를 나타내는 타입 */ export type TeamUser = { // ... (기존 속성) }; /** 프로젝트와 사용자 간의 관계를 나타내는 타입 */ export type ProjectUser = { // ... (기존 속성) }; // ... (다른 타입들에 대해서도 유사하게 적용)이렇게 하면 각 타입의 목적과 사용 맥락을 더 쉽게 이해할 수 있을 것입니다.
src/mocks/mockData.ts (1)
Line range hint
789-803: FILE_DUMMY 상수의 메모리 내 파일 처리 방식 변경에 대한 검토FILE_DUMMY의 타입을 FileInfo[]에서 TaskFileForMemory[]로 변경하고 Blob 타입의 'file' 속성을 추가한 것은 MSW 설정에 유용할 것 같습니다. 이는 파일 내용을 메모리에서 직접 처리할 수 있게 해줍니다.
그러나 다음 사항들을 고려해 주시기 바랍니다:
- 대용량 파일 처리 시 메모리 문제가 발생할 수 있으므로, 실제 환경에서의 사용에 주의가 필요합니다.
- 이 접근 방식의 목적과 사용 이유를 설명하는 주석을 추가하면 좋을 것 같습니다.
다음과 같은 주석을 추가하는 것이 어떨까요?
+ // MSW에서 파일 내용을 메모리에 저장하여 모의 파일 다운로드를 시뮬레이션합니다. + // 주의: 실제 환경에서는 대용량 파일 처리 시 메모리 이슈가 발생할 수 있습니다. export const FILE_DUMMY: TaskFileForMemory[] = [ // ... (현재 코드) ];src/mocks/services/taskServiceHandler.ts (2)
89-94:createTask함수 호출 시 중복된 데이터 전달을 피하세요
newTask객체를 생성한 후 동일한 데이터를createTask함수에 다시 전달하고 있습니다.newTask를 직접 전달하여 코드의 중복을 줄일 수 있습니다.다음과 같이 수정할 수 있습니다:
- const newTask = { ...taskInfoForm, statusId: taskInfoFormStatusId, taskId }; - createTask({ ...taskInfoForm, statusId: taskInfoFormStatusId, taskId }); + const newTask = { ...taskInfoForm, statusId: taskInfoFormStatusId, taskId }; + createTask(newTask);
292-310: 불필요한 조건문을 제거하여 코드 간결성을 높이세요
files.length === 0인 경우와 아닌 경우 모두files를 반환하고 있으므로 조건문 없이 바로 반환할 수 있습니다.다음과 같이 수정하세요:
- if (files.length === 0) return HttpResponse.json([]); - return HttpResponse.json(files.length === 0 ? [] : files); + return HttpResponse.json(files);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
- src/mocks/mockAPI.ts (1 hunks)
- src/mocks/mockData.ts (3 hunks)
- src/mocks/services/taskServiceHandler.ts (2 hunks)
- src/mocks/services/userServiceHandler.ts (1 hunks)
- src/types/MockType.tsx (1 hunks)
- src/utils/Validator.ts (0 hunks)
💤 Files with no reviewable changes (1)
- src/utils/Validator.ts
🧰 Additional context used
📓 Learnings (1)
src/mocks/services/taskServiceHandler.ts (2)
Learnt from: Seok93 PR: GU-99/grow-up-fe#155 File: src/mocks/services/taskServiceHandler.ts:107-107 Timestamp: 2024-09-24T07:02:17.215Z Learning: 최근 파일 타입 변경 사항에도 불구하고 `taskServiceHandler.ts`의 일정 파일 목록 검색 API는 업데이트가 필요하지 않습니다.Learnt from: Seok93 PR: GU-99/grow-up-fe#155 File: src/mocks/services/taskServiceHandler.ts:107-107 Timestamp: 2024-10-09T02:55:45.171Z Learning: 최근 파일 타입 변경 사항에도 불구하고 `taskServiceHandler.ts`의 일정 파일 목록 검색 API는 업데이트가 필요하지 않습니다.
🪛 Biome
src/mocks/mockAPI.ts
[error] 173-173: The assignment should not be in an expression.
The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.(lint/suspicious/noAssignInExpressions)
🔇 Additional comments (7)
src/types/MockType.tsx (1)
14-17: TaskUser 타입이 간결하게 정의되어 있습니다.TaskUser 타입은 작업과 사용자 간의 연관성을 잘 표현하고 있습니다.
다만, ProjectUser와 달리 roleId가 없는 것이 의도적인지 확인이 필요합니다. 작업 수준에서 역할이 적용되지 않는 것인지, 아니면 단순히 누락된 것인지 확인해 주세요. 만약 의도적이라면, 주석을 통해 그 이유를 명시하는 것이 좋겠습니다.
다음 스크립트를 실행하여 TaskUser의 사용 맥락을 확인해 보겠습니다:
src/mocks/services/userServiceHandler.ts (3)
97-97: API 기능 확장에 대한 구현 확인 필요API 엔드포인트에 대한 주석이 "전체 팀 목록 조회 API (가입한 팀, 대기중인 팀)"으로 변경되었습니다. 이는 API의 기능이 확장되었음을 시사합니다.
현재 구현이 이 확장된 기능을 정확히 반영하고 있는지 확인해 주세요. 특히 대기 중인 팀에 대한 처리가 추가되었는지 검토가 필요합니다.
103-103: userId 추출 방식 개선
convertTokenToUserId함수를 사용하여 accessToken에서 userId를 추출하는 방식으로 변경된 것은 좋은 개선입니다.이 변경으로 코드의 일관성과 유지보수성이 향상되었습니다.
Line range hint
118-138: teamJoinStatusList 구성 로직 검토 필요API 기능이 확장되어 대기 중인 팀도 포함하도록 변경되었지만,
teamJoinStatusList를 구성하는 로직은 변경되지 않았습니다.현재 로직이 대기 중인 팀을 올바르게 처리하고 있는지 확인해 주세요. 필요하다면
isPendingApproval필드를 활용하여 대기 중인 팀을 구분하는 로직을 추가하는 것이 좋을 것 같습니다.다음 스크립트를 실행하여
TEAM_USER_DUMMY에isPendingApproval필드가 존재하는지 확인할 수 있습니다:이 결과를 바탕으로 필요한 경우
teamJoinStatusList구성 로직을 조정해 주세요.✅ Verification successful
검토 완료:
isPendingApproval필드가teamJoinStatusList구성 로직에 올바르게 포함되고 사용되고 있습니다. 현재 로직은 대기 중인 팀을 적절하게 처리하고 있습니다.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if TEAM_USER_DUMMY includes isPendingApproval field # Test: Search for TEAM_USER_DUMMY declaration and its usage rg --type typescript -A 10 'TEAM_USER_DUMMY\s*=' src/mocks/mockData.tsLength of output: 107
Script:
#!/bin/bash # Description: Check if TEAM_USER_DUMMY includes isPendingApproval field # Search for TEAM_USER_DUMMY declaration in .ts files and include 10 lines of context rg -A 10 'TEAM_USER_DUMMY\s*=' --glob '*.ts'Length of output: 46
Script:
#!/bin/bash # Description: Check if any TypeScript file includes isPendingApproval field # Search for isPendingApproval in .ts files and include 10 lines of context rg 'isPendingApproval' --glob '*.ts' -A 10Length of output: 9125
src/mocks/mockData.ts (2)
9-9: 타입 정의의 중앙화를 통한 코드 구조 개선타입 정의를 '@/types/MockType'에서 가져오도록 변경한 것은 좋은 리팩토링 접근 방식입니다. 이는 코드의 유지보수성을 향상시키고 타입 정의의 일관성을 보장하는 데 도움이 됩니다.
Line range hint
767-779: TASK_FILE_DUMMY의 타입 변경 승인 및 영향 확인 요청TASK_FILE_DUMMY의 타입을 TaskFile[]에서 UploadTaskFile[]로 변경한 것은 적절해 보입니다. 이는 태스크 파일의 용도를 더 명확히 하고 타입 안전성을 향상시킬 것입니다.
하지만 이 변경이 다른 부분의 코드에 미치는 영향을 확인해 주시기 바랍니다. 특히 이 더미 데이터를 사용하는 다른 부분들이 새로운 타입과 호환되는지 검증이 필요합니다.
src/mocks/services/taskServiceHandler.ts (1)
375-385: 일정 삭제 후 상태 내 일정들의 정렬이 올바른지 확인하세요
deleteTask후에reorderTaskByStatus를 호출하여 일정들을 재정렬하고 있습니다. 재정렬 로직이 제대로 동작하는지 검증이 필요합니다.다음 스크립트를 실행하여 재정렬이 올바르게 이루어졌는지 확인하세요:
위 스크립트는 해당 상태의 일정들의
sortOrder가 올바르게 설정되었는지 확인합니다.
PR Type
What kind of change does this PR introduce?
Related Issues
What does this PR do?
Other information
점진적으로 MSW 처리를 리팩토링할 예정이고, 이번 PR에서는 TaskService 관련 기능을 리팩토링했습니다.