Skip to content

IT-Cotato/11th-FE-Networking-June-1

Repository files navigation

6월 파트별 네트워킹 과제: 컴포넌트 단위 리팩토링

6월 파트별 네트워킹 과제인 컴포넌트 단위 리팩토링에 대한 가이드라인입니다.

🚀 과제 개요

이번 과제의 목표는 단일 파일(App.tsx)에 복합적으로 모여있는 코드를 논리적인 여러 컴포넌트와 커스텀 훅으로 분리하여 가독성, 유지보수성, 확장성을 높이기입니다.

CSS의 경우, 파트원분들이 선호하는 라이브러리가 다 달라서 인라인 스타일로 구현하였는데, 편한 CSS 라이브러리를 사용하셔도 됩니다 👍🏻

(인라인 스타일로 구현하여서 코드가 굉장히 길어보이는데 실제로는 그렇게까지는 길지 않습니다 ㅎㅎ..)

🎯 과제 목표

  • 컴포넌트 아키텍쳐 설계: 논리적이고 재사용 가능한 컴포넌트 계층 구조로 분해

  • 커스텀 훅 설계: 데이터 페칭, 상태 관리 등 공통 로직을 단일 책임을 가진 커스텀 훅으로 분리

  • 전역 상태 관리: 다크/라이트 모드 전환 기능을 Context API, Zustand 등 원하는 방식으로 구현

  • 상태 간 의존성 관리: 프로젝트 선택 시 관련 할 일 목록이 변경되는 등 상태 간의 의존성을 효과적으로 처리

  • 페이지와 컴포넌트 간의 상태 분리 전략 세우기: 어떤 상태를 페이지 단위에서 관리하고, 어떤 상태를 개별 컴포넌트 단위에서 관리할지 고민해보기


📝 주요 기능 요구사항

  1. 프로젝트 목록: API에서 프로젝트 목록을 가져와 표시합니다. 프로젝트 클릭 시 해당 프로젝트가 '선택' 상태가 되어야 합니다.

  2. 할 일 목록: 선택된 프로젝트에 속한 할 일(Task) 목록을 API에서 가져와 표시합니다.

  3. 할 일 필터링 및 검색:

    • 상태(To Do, In Progress, Done)별로 할 일 목록을 필터링할 수 있어야 합니다.
    • 할 일 제목으로 목록을 검색할 수 있어야 합니다.
  4. 할 일 추가: 선택된 프로젝트에 새로운 할 일을 추가하는 폼을 제공합니다. 이 폼에서는 할 일의 담당자를 전체 사용자 목록에서 선택할 수 있어야 합니다.

  5. 할 일 상태 변경: 각 할 일 항목에서 상태를 변경할 수 있는 드롭다운 메뉴를 제공합니다.

  6. 테마 변경: 다크/라이트 모드 토글 시 애플리케이션의 전반적인 색상이 변경되어야 합니다.


📡 API 명세 (MSW)

본 과제는 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 경로) 특정 작업의 상태를 수정합니다.

Git 사용법

  • 본 과제는 해당 repository를 fork하는 방식이 아닌 clone을 통해 진행

  • 본 repository를 clone한 이후 본인 이름으로 branch를 생성 후 작업 (예시: git checkout -b kitak)

  • 과제 구현 이후 본 repository의 develop branch를 target으로 Pull Request 작성

  • PR 제목 : [Refactor]: (이름) 6월 파트별 네트워킹 과제 제출


Pull Request(PR) 작성 표준 템플릿

제출 기한: 6월 27일 오후 3시

리팩토링 작업 완료 후, 아래의 표준 템플릿을 활용하여 PR을 작성하여 다른 프론트엔드 파트원들이 보았을 때, 이해를 도울 수 있게 PR을 작성할 것 탬플릿을 사용하는 것을 권장하지만, 자신의 코드를 더 잘 설명할 수 있는 방향이 있으면 원하시는대로 PR 탬플릿을 가져오셔도 좋습니다!  

## ✨ 주요 변경 사항

(예시)
- `App.tsx`를 기능 단위의 컴포넌트(예: `ProjectList`, `TaskList`)로 분리했습니다.
- 데이터 페칭 및 상태 관리 로직을 커스텀 훅(예: `useProjects`, `useTasks`)으로 추출했습니다.
- 다크/라이트 모드 테마 기능을 위한 전역 상태 관리를 구현했습니다.
- 프로젝트 선택 시 관련 할 일 목록이 업데이트되는 의존성을 처리했습니다.

## 📚 리팩토링 상세 내용

### 1. 컴포넌트 분리

- **대상 기능 또는 코드**: `[분리 대상이 된 기존 기능 또는 코드 설명]`

- `[새로 생성된 컴포넌트명]` - (담당 기능: `[컴포넌트의 기능]`)

- **분리 근거**: `[단일 책임 원칙, 재사용성, 가독성 등 분리 이유 작성]`



### 2. 커스텀 훅 분리

- **대상 코드**: `[분리 대상이 된 코드]`

- **분리된 훅**: `[새로 생성된 훅 이름]`

- **분리 근거**: `[상태 로직 그룹화, 관심사 분리, 로직 재사용성 등 분리 이유 작성]`


### 3. 전역 상태 관리

- **구현 기능**: (예시) 다크/라이트 모드 테마 변경

- **사용한 기술**: `[Context API, Zustand, Recoil 등 사용한 기술 명시]`

- **설계 이유**: [기술 선택 이유 및 설계 이유 작성]


### 4. 상태 간 의존성 관리

- **의존 관계**: (예시) `선택된 프로젝트(selectedProject)``할 일 목록(tasks)`

- **처리 방식**: [처리 방식 작성] 


## 다른 파트원에게 궁금한 점

- ~~ 기능 분리 시 ~~가 고민이었는데 어떻게 하셨는지 궁금합니다 등
- (그 외 자유롭게 질문 및 고민 사항을 작성해 주세요.) 

About

6월 프론트엔드 파트별 네트워킹(1)(컴포넌트 단위)을 위한 레포지토리입니다.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published