6월 파트별 네트워킹 과제인 컴포넌트 단위 리팩토링에 대한 가이드라인입니다.
이번 과제의 목표는 단일 파일(App.tsx
)에 복합적으로 모여있는 코드를 논리적인 여러 컴포넌트와 커스텀 훅으로 분리하여 가독성, 유지보수성, 확장성을 높이기입니다.
CSS의 경우, 파트원분들이 선호하는 라이브러리가 다 달라서 인라인 스타일로 구현하였는데, 편한 CSS 라이브러리를 사용하셔도 됩니다 👍🏻
(인라인 스타일로 구현하여서 코드가 굉장히 길어보이는데 실제로는 그렇게까지는 길지 않습니다 ㅎㅎ..)
-
컴포넌트 아키텍쳐 설계: 논리적이고 재사용 가능한 컴포넌트 계층 구조로 분해
-
커스텀 훅 설계: 데이터 페칭, 상태 관리 등 공통 로직을 단일 책임을 가진 커스텀 훅으로 분리
-
전역 상태 관리: 다크/라이트 모드 전환 기능을 Context API, Zustand 등 원하는 방식으로 구현
-
상태 간 의존성 관리: 프로젝트 선택 시 관련 할 일 목록이 변경되는 등 상태 간의 의존성을 효과적으로 처리
-
페이지와 컴포넌트 간의 상태 분리 전략 세우기: 어떤 상태를 페이지 단위에서 관리하고, 어떤 상태를 개별 컴포넌트 단위에서 관리할지 고민해보기
-
프로젝트 목록: API에서 프로젝트 목록을 가져와 표시합니다. 프로젝트 클릭 시 해당 프로젝트가 '선택' 상태가 되어야 합니다.
-
할 일 목록: 선택된 프로젝트에 속한 할 일(Task) 목록을 API에서 가져와 표시합니다.
-
할 일 필터링 및 검색:
- 상태(To Do, In Progress, Done)별로 할 일 목록을 필터링할 수 있어야 합니다.
- 할 일 제목으로 목록을 검색할 수 있어야 합니다.
-
할 일 추가: 선택된 프로젝트에 새로운 할 일을 추가하는 폼을 제공합니다. 이 폼에서는 할 일의 담당자를 전체 사용자 목록에서 선택할 수 있어야 합니다.
-
할 일 상태 변경: 각 할 일 항목에서 상태를 변경할 수 있는 드롭다운 메뉴를 제공합니다.
-
테마 변경: 다크/라이트 모드 토글 시 애플리케이션의 전반적인 색상이 변경되어야 합니다.
본 과제는 MSW
(Mock Service Worker)를 사용하여 실제 백엔드 서버 없이 API 통신을 모킹합니다.
MSW
설정은 다 해놨으니, 제가 준 예시 App.tsx
코드를 예시로 사용해주시면 됩니다 😊
src/mock/handlers.ts
보시면 MSW
를 모르셔도 이해하실 수 있을거에요!
Method | Path | Parameters | Description |
---|---|---|---|
GET |
/api/projects |
없음 | 전체 프로젝트 목록을 조회합니다. |
GET |
/api/users |
없음 | 전체 사용자 목록을 조회합니다. |
GET |
/api/tasks |
projectId (쿼리 스트링) |
특정 프로젝트의 작업 목록을 조회합니다. |
POST |
/api/tasks |
없음 (Body: Task 정보) |
새로운 작업을 생성합니다. |
PATCH |
/api/tasks/:taskId |
taskId (URL 경로) |
특정 작업의 상태를 수정합니다. |
-
본 과제는 해당 repository를 fork하는 방식이 아닌 clone을 통해 진행
-
본 repository를 clone한 이후 본인 이름으로 branch를 생성 후 작업 (예시: git checkout -b kitak)
-
과제 구현 이후 본 repository의 develop branch를 target으로 Pull Request 작성
-
PR 제목 : [Refactor]: (이름) 6월 파트별 네트워킹 과제 제출
리팩토링 작업 완료 후, 아래의 표준 템플릿을 활용하여 PR을 작성하여 다른 프론트엔드 파트원들이 보았을 때, 이해를 도울 수 있게 PR을 작성할 것 탬플릿을 사용하는 것을 권장하지만, 자신의 코드를 더 잘 설명할 수 있는 방향이 있으면 원하시는대로 PR 탬플릿을 가져오셔도 좋습니다!
## ✨ 주요 변경 사항
(예시)
- `App.tsx`를 기능 단위의 컴포넌트(예: `ProjectList`, `TaskList`)로 분리했습니다.
- 데이터 페칭 및 상태 관리 로직을 커스텀 훅(예: `useProjects`, `useTasks`)으로 추출했습니다.
- 다크/라이트 모드 테마 기능을 위한 전역 상태 관리를 구현했습니다.
- 프로젝트 선택 시 관련 할 일 목록이 업데이트되는 의존성을 처리했습니다.
## 📚 리팩토링 상세 내용
### 1. 컴포넌트 분리
- **대상 기능 또는 코드**: `[분리 대상이 된 기존 기능 또는 코드 설명]`
- `[새로 생성된 컴포넌트명]` - (담당 기능: `[컴포넌트의 기능]`)
- **분리 근거**: `[단일 책임 원칙, 재사용성, 가독성 등 분리 이유 작성]`
### 2. 커스텀 훅 분리
- **대상 코드**: `[분리 대상이 된 코드]`
- **분리된 훅**: `[새로 생성된 훅 이름]`
- **분리 근거**: `[상태 로직 그룹화, 관심사 분리, 로직 재사용성 등 분리 이유 작성]`
### 3. 전역 상태 관리
- **구현 기능**: (예시) 다크/라이트 모드 테마 변경
- **사용한 기술**: `[Context API, Zustand, Recoil 등 사용한 기술 명시]`
- **설계 이유**: [기술 선택 이유 및 설계 이유 작성]
### 4. 상태 간 의존성 관리
- **의존 관계**: (예시) `선택된 프로젝트(selectedProject)` → `할 일 목록(tasks)`
- **처리 방식**: [처리 방식 작성]
## 다른 파트원에게 궁금한 점
- ~~ 기능 분리 시 ~~가 고민이었는데 어떻게 하셨는지 궁금합니다 등
- (그 외 자유롭게 질문 및 고민 사항을 작성해 주세요.)