[4팀 이연성] Chapter 2-3. 관심사 분리와 폴더구조

[LEEYEONSEONG]

배포 링크

• https://front-5th-chapter2-3-git-main-leeyeonseongs-projects.vercel.app/

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?

체크포인트

• 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
• Props Drilling을 최소화했나요?
• shared 공통 컴포넌트를 분리했나요?
• shared 공통 로직을 분리했나요?
• entities를 중심으로 type을 정의하고 model을 분리했나요?
• entities를 중심으로 ui를 분리했나요?
• entities를 중심으로 api를 분리했나요?
• feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
• feature를 중심으로 ui를 분리했나요?
• feature를 중심으로 api를 분리했나요?
• widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

• 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
• 쿼리 키가 적절히 설정되었는가?
• fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?

과제 셀프회고

과제에서 좋았던 부분

• 상태관리 라이브러리를 Context 대신 Zustand로 사용하면서 코드가 훨씬 간결해졌습니다.
• TanStack Query를 통해 API 요청 흐름이 선언형으로 개선되었고, 캐싱 구조도 이해할 수 있었습니다.

과제를 하면서 새롭게 알게된 점

과제를 진행하면서 아직 애매하게 잘 모르겠다 하는 점, 혹은 뭔가 잘 안되서 아쉬운 것들

• FSD 구조를 처음 설계해보는 것이라 어디서부터 어떻게 시작해야 할지 몰랐습니다.
• 일단은 제 생각대로 entities → features → widgets → pages 순서로 코드를 나눠보았지만,
  이 계층 분리가 실제로 FSD 철학에 부합하는지 확신이 부족합니다.
• 특히 features와 widgets의 경계가 애매하게 느껴졌고, 상태와 UI의 분리 기준이 헷갈렸습니다.
• 실무에서는 어떤 기준과 흐름으로 FSD를 설계하는지, 또는 설계 전에 어떤 사고 순서를 가지면 좋은지 조언을 듣고 싶습니다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

• FSD 구조 설계 시, 실무에서는 어떤 순서로 생각하고 계층을 나누시는지 궁금합니다.
  예를 들어 도메인 개념부터 먼저 나누는지, 혹은 공통 UI부터 먼저 정의하는지 등의 접근 방식이 궁금합니다.