📕 과제 체크포인트
https://geonhwiii.github.io/front_6th_chapter2-3/
기본과제
목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 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가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
- 캐싱과 리프레시 전략이 올바르게 구현되었는가?
- 낙관적인 업데이트가 적용되었는가?
- 에러 핸들링이 적절히 구현되었는가?
- 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
- 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
- TanStack Query의 Devtools가 정상적으로 작동하는가?
최종과제
- 폴더구조와 나의 멘탈모데일이 일치하나요?
- 다른 사람이 봐도 이해하기 쉬운 구조인가요?
📕 과제 셀프회고
📙 이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.
1. FSD 아키텍처
2. React Query 도입의 효과
솔직히 React Query를 도입하기 전과 후의 코드로 나뉠정도로, 리팩토링을 해도 코드가 깔끔해지지 않았습니다.
서버의 상태과 클라이언트의 상태가 혼합되어 있다보니, 가독성도 개선이 되지 않고, 로직분리도 어려웠습니다.
React Query를 사용함으로써 해당 로직을 덜어내고나니 리팩토링도 훨씬 편해졌습니다.
3. 공용 요청 client
그냥 fetch로 과제를 마무리하려고 했지만, 배포때 서버 endpoint관리를 위해 Api Client를 만들어 사용했습니다.
만들기 전에는 쿼리파라미터 관리가 힘들었는데, client에서 쿼리파터를 관리함으로써 이점이 크게 느껴져서,
다음부턴 api 요청이 있을땐 먼저 client를 만드는게 당연히 맞겠다...싶었습니다.
리팩토링을 해야지, 라는 마인드보단 내 어플리케이션을 만든다. 라는 마인드로 개발을 했으면 더 좋았을 것 같습니다.
리팩토링을 하려다보니, 계속 저만의 앱을 만드는 패턴을 사용하지 않게 되는 것 같아 그 점이 저에게 아쉬웠습니다.
본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?
과제의 본질인 "관심사 분리와 폴더구조"에 집중했습니다.
코드를 깔끔하게 가져가는 것도 물론 중요하지만, 이번 과제에 꼭 배워가고 싶은 부분은 폴더구조였던 것 같습니다.
그래서 이번엔 평소와 다르게, 폴더구조를 먼저 잡고 시작을 해보았습니다.
features 폴더 구조에서 시험을 해본 것은 Nextjs의 Routes Group처럼 소괄호를 이용해 그룹화하였습니다.
🎯 Features 레이어 구조
src/features/
├── (post)/
│ ├── add-post/
│ │ ├── ui/
│ │ │ └── add-post-dialog.tsx
│ │ ├── model/
│ │ │ └── useAddPost.ts
│ │ └── index.ts
│ ├── search-posts/
│ │ ├── ui/
│ │ │ └── search-input.tsx
│ │ ├── model/
│ │ │ └── usePostSearch.ts
│ │ └── index.ts
│ ├── filter-by-tag/
│ ├── list-posts/
│ └── view-post-detail
└── (comment)/
├── add-comment/
├── list-comments/
└── edit-comment/
└── (user)/
📁 Entities 레이어 구조
src/entities/
├── post/
│ ├── api/
│ │ ├── get-posts.ts
│ │ ├── search-posts.ts
│ │ ├── add-post.ts
│ │ └── index.ts
│ ├── model/
│ │ ├── types.ts
│ │ └── index.ts
│ ├── lib/
│ │ ├── enrich-posts-with-authors.ts
│ │ └── index.ts
│ ├── ui/
│ └── index.ts
├── comment/
│ ├── api/
│ ├── model/
│ └── ui/
├── user/
└── tag/
📙아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.
과제 코드에서 개선해야 되는 부분은 아직 많은 것 같습니다.
"관심사 분리와 폴더 구조" 라는 주제로만 보았을 때,
이번 과제는 기능이 명확히 나눠져있어서 상대적으로 분리하기 용이했던 것 같습니다.
다양한 프로젝트에서 적용해보면서 익혀나가야겠습니다.
📙 이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.
실제로 회사에서 나홀로 프로젝트(?)로 웹개발을 진행중인데, FSD 아키텍처로 개발을 진행하고 있습니다.
단순히 폴더를 나누는 것이 아닌, 기능에 대해서 고민하면서 개발을 진행하니
이전보다 조금 더 탄탄한 프로젝트 구성이 되어가는 것 같아 뿌듯합니다.
📕 챕터 셀프회고
처음 봤을 때는 솔직히 "이걸 어떻게 고치지?" 라는 막막함이 컸습니다.
평소에 제가 작성하는 코드와는 달리, 다른 사람이 작성한 코드를 분석하고 개선하는 것이 생각보다 훨씬 어려웠습니다.
특히 여러 비즈니스 로직이 하나의 컴포넌트에 뒤엉켜 있을 때, "이어디서부터 손을 대야 하지?" 싶은 순간들이 많았습니다.
하지만 점진적으로 함수를 분리하고, 책임을 나누면서 코드가 점점 읽기 쉬워지는 과정을 경험하니, 수정이 점점 재미있어졌습니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
과제 피드백
건휘님! 이번 주차는 과제 달성률이 많이 떨어지는데 역시나 건휘님은 잘 해내셨군요 :) 멋집니다!
넵 말씀하신대로 저도 리액트 쿼리의 효능을 참 많이 좋아하는데요. 특히나 리액트 쿼리의 캐시로 인해 데이터를 교환하거나 패칭을 한 번만 할 목적으로 상태관리도구를 사용하는 경우가 많이 줄었어요. 오히려 단순히 공유를 목적으로하는 상태관리도구의 사용성이 줄어드니 비즈니스 로직을 담는 역할에 더 충실해지는 것 같기도 하고요 :) 그리고 공용 요청 client라고 부르신 API 패칭 레이어는 제 생각에는 모든 프로젝트에서 반드시 필요한 레이어가 아닐까 생각해요. API 호출은 일단 한 번 추상화하고 봐야합니다. 그로인해서 여러가지 장점을 취할 수 있어욥.
주말 잘 보내세요!