https://tooth-is-silver.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가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

아래는 fsd 작업 진행 순서입니다. 각 레이어를 구분하면서 고민했던 내용을 함께 정리해 보았아요.

## shared 구성 (최하위)

1. User, API 응답과 같은 여러 레이어에 공유되는 정보를 담는다.
2. 내부 폴더 이름은 목적이 명확해야 한다. components, hooks, types같은 모호한 이름은 사용하지 않는다.
3. 공통으로 사용되는 유틸리티와 UI 컴포넌트를 담는다.
4. shared 내부에서 shared 레이어 공유 가능하다.
5. shared 폴더는 도메인(slices) 폴더가 없다. segment로만 이루어져있다.

## entities 구성

1. 핵심 데이터 구조와 상태 관리를 담는다. ex. Product model, User model, Order model, Review model
2. 핵심 데이터를 CRUD하는 API request function을 구성한다. (api)
3. 여러 page에서 재사용이 가능한 엔티티 interface들도 구성될 수 있다.
4. 단순한 데이터 구조 뿐만 아니라 비즈니스 로직을 포함한다. ex. User 엔티티의 경우엔 login, signup을 포함

import { getUsers } from "entities/users"
import { createUser } from "features/users"

export interface PostCommentsObj {
  [key: number]: Array<Comments>
}

export interface PostsWithUsers extends Post {
  author?: Users | undefined
}

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

레이어의 하위 참조

props drilling에 대한 고찰

전역상태를 이용해서 props drilling을 정리해보았습니다. 정말 컴포넌트만 남기니 깔끔하고 속이 뻥 뚫릴 정도로 시원해졌으나, 코치님이 얘기해주신대로 어떤 컴포넌트가 어떤 상태값과 어떤 액션을 취할 수 있는지 판단이 힘들었습니다. 내부 로직을 개선해야할때면 props drilling때와 마찬가지로 내부에 들어가거나 관련된 hook이나 액션을 찾아야 로직 파악이 가능했었습니다. 그래서 이 부분에 있어서는 꼭 props drilling이 나쁜것인가? 라고 했을때 아니다라고 자신있게 얘기할 수 있을 것 같습니다. 공용 컴포넌트에 전달하는 props들처럼 해당 컴포넌트를 위한 ui props만 무조건 사용해야하나? 라고 했을때도 아니다라고 얘기할 수 있을 것 같습니다.

구조적 응집도

과제를 진행하면서 얼마나 응집도가 높아야하는지 느껴본 시간이었던 것 같고, 이 높은 응집도를 위해서는 정말 많은 시간과 노력이 필요하구나.. 단 일주일 이었지만 이 작은 프로젝트에도 리팩토링하기엔 너무나도 부족한 시간이었고 fsd가 과연 좋은 패턴일까에 대한 고민도 많았습니다. 실무에서 직접 fsd를 적용해보면서 여러 도메인에서는 어떤 패턴이 나을지 부딛혀보는 수밖에 없을 것 같아 이번 배움은 이정도면 충분한 것 같다고 느낍니다!

그리고 리팩토링을 위해 useState를 모두 전역 상태값으로 빼야하는가? 를 많이 고민했던 것 같습니다. selectedPost같은 ui에서 사용하는 가공된 데이터 값을 전역 상태값으로 넣자니 공용 데이터도 아닌 것이 그렇다고 ui를 위한 상태 값도 아니니 props로 전달하기가 애매했습니다.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

커스텀 훅을 다양하게 사용하고 이 보다 더러운 코드는 없을테니 많은 양의 코드를 보는 눈썰미가 길러졌을 것 같다 라는 긍정적인 생각이 들었습니다!

챕터 셀프회고

클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

• 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

응집도 높이기: 서버상태관리, 폴더 구조

• "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

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

page 내부의 useEffect

// URL 동기화를 위한 useEffect
useEffect(() => {
  updateURL()
}, [skip, limit, sortBy, sortOrder, selectedTag])

// URL 파라미터 초기화
useEffect(() => {
  const params = new URLSearchParams(location.search)
  setSkip(parseInt(params.get("skip") || "0"))
  setLimit(parseInt(params.get("limit") || "10"))
  setSearchQuery(params.get("q") || "")
  setSortBy(params.get("sortBy") || "")
  setSortOrder(params.get("sortOrder") || "asc")
  setSelectedTag(params.get("tag") || "")
}, [location.search, setSkip, setLimit, setSearchQuery, setSortBy, setSortOrder, setSelectedTag])

보통의 useEffect는 해당 의존성배열 값들이 사용되는 컴포넌트로 분리하여 사용하였는데 이번에는 파라미터를 가져와서 세팅하는 부분이다보니 page가 맞는가..? 그렇다고 router영역은 아닌거 같고, 내부 컴포넌트로 가져가는 것도 아닌것 같다는 생각이 들어 PostsManagerPage에 그대로 두었습니다. 어떻게 개선하면 좋았을지 궁금합니다.

page 내부의 게시물 상세

   {/* 게시물 상세 보기 대화상자 */}
    <PostDetailDialog children={<CommentList />} />

해당 코드를 보면 내부에 children으로 컴포넌트를 전달하고 있습니다. 외부에 한번 더 감싸서 감출지 혹은 PostDetailDialog내부에 넣지 말고 PostDetailDialog를 풀어놓고 내부 CommentList만 컴포넌트화 할지 고민이었는데 가장 보기 편한 방법이 이 방법인 것 같아서 children으로 props를 받는 방법을 선택했습니다. 막상 children으로 받고 나니 features/ui 내부에 features/ui를 children으로 받는 형태여서 features/ui내부에 widgets/ui를 받는게 낫지않았을까.. 라는 생각도 들었습니다. 어떤 더 나은 방법이 있을지 궁금합니다.