[11팀 김도형] Chapter 2-3. 관심사 분리와 폴더구조

[d5br5]

과제 체크포인트

배포 링크

• https://d5br5.github.io/front_5th_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가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?

과제 셀프회고

빠르게 과제를 완료할 수 있을거라 생각했는데, 생각보다 시간이 너무 많이 소요되었습니다. 과제전형 응시 + 회사 업무 바빠짐 이슈로 수요일에 과제를 시작했는데,, ㅜㅜ 일찍 시작했으면 좀 더 완성도를 높일 수 있지 않았을까 하는 아쉬움이 남습니다.

그래도 이제 FSD가 뭔지 어느정도는 알게 된 것 같아 좋습니다. (근데 이게 저에게 딱 맞는 구조는 아닌 것 같아서 앞으로 자주 사용할지는 모르겠습니다.)

과제 설명을 보고, 기본 심화를 구분하지 말고 처음부터 RQ + zustand를 적용해서 분리해보자! 는 마인드로 시작했습니다.
과정이 쉽지는 않았지만, 나눠서 진행했으면 더 오래걸렸을 것 같네요. 그래도 잘 마무리해서 좋습니다.

과제에서 좋았던 부분

• 정리되지 않은 코드의 구조를 파악하고, 분리하는 과정을 겪을 수 있어 좋았습니다. 추후 다른 팀으로 합류하여 새로운 코드를 접하게 되더라도, 구조를 어찌저찌 잘 파악해나갈 수 있겠다는 자신감을 얻었습니다.
• props drilling을 최소화하고, zustand store를 사용하여 전역 상태관리를 경험할 수 있어 좋았습니다.
• react-query를 사용해, 서버 데이터와 클라이언트 상태를 구분해볼 수 있어 좋았습니다.

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

• react-query를 많이 사용해보지 못했는데, 이제 구조와 사용 방법에 대해 좀 알게된 것 같습니다.
• FSD에 대해 잘 몰랐는데, 이제 좀 알게된 것 같습니다.

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

• FSD가 무엇인지 이제야 조금 알게된 느낌인데, 아직 능숙하게 다루지는 못하는 것 같습니다.

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

고민을 오래 했는데, 명쾌하게 정리하지 못한 부분 질문드립니다.

1. 같은 레이어 계층을 import해서 사용하면 안되는건가요? 안된다고 배우긴 했지만, 가끔 괜찮다는 자료도 본 것 같아서요. 실제로 GPT도 괜찮다고 대답해주고.. 잘 개발하고 있다가 동일 레이어 import가 발생하면 둘 중 하나를 위 레이어로 옮기는 작업을 매번 수행해주는 것도 은근히 불편한 것 같습니다. 구체적인 예시는 들지 못하겠지만, 동일 레이어 import를 막으면 entity, feature, widget 말고 한 단계가 더 있어야 할 것 같은 느낌도 가끔 받습니다 (process는 적합하지 않고..) . 일관적으로 사용하기만 한다면, 동일 레이어 import를 일부 허용해도 괜찮을까요?

2.. post를 조회하는 로직이 비슷한 종류로 3가지 있었습니다. 일반 게시물 조회 / 태그별 게시물 조회 / 게시물 검색. 이들은 각각 응답 구조가 같고, 모두 user 데이터랑 결합해서 사용했습니다. 그래서 저는 다음과 같이 세 타입의 쿼리를 묶은 새로운 쿼리를 만들었습니다.

export const usePosts = () => {
  const { data: normalPosts, isLoading: normalPostsLoading } = useNormalPosts()
  const { data: tagPosts, isLoading: tagPostsLoading } = useTagPosts()
  const { data: searchPosts, isLoading: searchPostsLoading } = useSearchPosts()

  const posts = useMemo(() => {
    if (searchPosts) {
      return searchPosts
    }
    if (tagPosts) {
      return tagPosts
    }
    if (normalPosts) {
      return normalPosts
    }
  }, [normalPosts, tagPosts, searchPosts])

  const isLoading = normalPostsLoading || tagPostsLoading || searchPostsLoading

  return { data: posts, isLoading }
}

user랑 결합하는 로직에서는 post 데이터가 어떤 종류의 post인지 신경쓰지 않으므로, 이렇게 묶어서 은닉화하고자 하는 의도도 있었습니다.
제가 궁금한건, 1. 이렇게 훅을 결합해서 사용하기도 하는가. 2. 결합된 이 훅은 어느 레이어에 배치해야 하는가 입니다.
일단 사용해도 괜찮다는 가정하에, entity layer는 아닌 것 같고, feature에 배치해야 하나? 그렇다면 이 훅은 widget 이상에서만 사용할 수 있나..? 이런 생각이 들어서요. (1번 질문과 어느정도 이어집니다.. ㅎㅎ) 이 훅에 대한 코치님의 의견이 궁금합니다. (나라면 이렇게 훅을 구성했을 것 같다. 어느 레이어에 배치했을 것 같다. 혹은 이렇게 만들지 않았을 것 같다)

3. post 데이터와 user 데이터를 결합하는 로직은 헬퍼 함수로 만드는 것으로 충분할까요? 아니면 묶는 로직까지 포함해서 상위 훅으로 만드는게 좋을까요..?

4. queryClient 캐시 무효화/자체 수정 관련 질문입니다. 댓글 삭제/게시물 수정 등 mutation 로직을 수행할 때, 결과 업데이트 하는 방식에는 두 가지가 있다고 생각합니다. 1. 관련 쿼리를 invalidate해서, 그 데이터를 사용하는 컴포넌트에서 refetch 수행 / 2. queryClient cache에 저장된 값을 모두 순회하며, 직접 업데이트
   1번 방식은, 코드 작성하는 입장에서 (세부 업데이트 로직을 생각하지 않아도 된다는 점에서)편하다는 장점이 있지만, 추가적으로 API 호출이 발생합니다. 2번 방식은, API 호출은 막지만, 세부 업데이트 로직을 생각해야 해서 번거로운 면이 있습니다. 서비스가 커지면 업데이트 로직이 거대해지기도 합니다.

코치님은 어떤 방식을 더 선호하시나요? 혹은 어떤 방식이 더 옳다고 생각하시나요?

감사합니다. 연휴 잘 보내세요 :)