[11팀 이민기] Chapter 2-3. 관심사 분리와 폴더구조

[lapidix]

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 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가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?

배포 링크

https://mingi3442.github.io/front_5th_chapter2-3/

과제 셀프회고

과제에서 좋았던 부분

실무에서 충분히 사용하는 tanstack-query와 zustand를 이용해서 리팩토링을 진행하여 해당 라이브러리에 대한 이해도와 함께 리팩토링에 대한 연습을 진행해서 좋았습니다.

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

이번에 tanstack-query를 이용해야 한다는 생각에 매몰되어서 낙관적 업데이트를 하고 쿼리를 재요청하지 않는 방법으로 해야하나? 라는 생각에 빠져버렸습니다.
그래서 그 방법에 대해 찾아보다가 queryClient.setQueryData에 대해 알게 되었고, 낙관적 업데이트 말고 정말 요청이 된 이후인 onSuccess에서 사용하면 되지 않을까? 라는 생각으로 리팩토링을 진행했습니다.
그러나 마지막에 zustand를 이용해서 posts와 comments를 관리했어야 했구나라는 생각을 했습니다..
덕분에 queryClient.setQueryData에 대해 알게 되었지만, 전역 상태관리를 통해 해결할 수 있던 일을 비효율적으로 해결한 것 같아서 아쉽습니다.

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

검색 기능을 위해 createQueryParamsStore을 만들었습니다. 훅을 리턴하는 팩토리 패턴을 사용하였는데 store와 같이 쓰기 위해 사용을 했지만 이게 올바르게 구현한 것인지에 대한 의문점이 아직도 남습니다. 또한 검색 기능 자체가 제가 원하는 대로 작동하지 않아서 너무 아쉬웠습니다. 이 부분은 항해가 끝난 이후에 다시 해볼 계획입니다..

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

1. FSD와 Next.JS
   공식문서에서 app/에서 providers를 관리하는 것으로 확인했었습니다. 프로바이더로 루트 레이아웃을 감싸는 경우가 많은데, 그러나 프로바이더가 클라이언트 컴포넌트일 경우 하위 컴포넌트들도 서버 컴포넌트 더라도 클라이언트 사이드 렌더링을 하는 것으로 알고 있습니다. 이럴 경우 서버 컴포넌트로 만드는 것들이 무의미해지는 것 같은데 이런 경우 어떻게 개선 가능할지 혹은 코치님은 어떻게 하실지 궁금합니다. 아래는 FSD 공식 사이트 example에 있는 한 프로젝트의 provider 코드 중 하나입니다!
   https://github.com/penteleichuk/Moke-Smoke/blob/main/src/app/providers/ThemeProvider/ui/ThemeProvider.tsx

import React, { FC, useEffect } from 'react';
import { Appearance } from 'react-native';
import { useAppDispatch } from 'shared/lib/state/dispatch/useAppDispatch';
import { useAppSelector } from 'shared/lib/state/selector/useAppSelector';
import { getColorScheme } from './../model/selectors/getColorScheme/getColorScheme';
import { getTheme } from './../model/selectors/getTheme/getTheme';
import { setTheme } from './../model/slice/themeSlice';

interface ThemeProviderProps {
  children: React.ReactNode;
}

export const ThemeProvider: FC<ThemeProviderProps> = ({ children }) => {
  const colorScheme = useAppSelector(getColorScheme);
  const theme = useAppSelector(getTheme);

  const dispatch = useAppDispatch();

  Appearance.addChangeListener(preferences => {
    if (preferences.colorScheme && colorScheme === 'system') {
      if (theme !== preferences.colorScheme) {
        dispatch(setTheme(preferences.colorScheme));
      }
    }
  });

  useEffect(() => {
    if (colorScheme === 'system') {
      const system = Appearance.getColorScheme() || 'dark';
      if (system !== theme) {
        dispatch(setTheme(system));
      }
    } else {
      if (theme !== colorScheme) {
        dispatch(setTheme(colorScheme));
      }
    }
  }, [colorScheme]);

  return children;
};

2. features -> features
   제가 이전 과제에서 받은 피드백대로 features에서 features를 사용하는 것은 FSD 원칙을 위배하기 때문에 개선을 하려고 해도 도저히 상상이 안갑니다.. 멘토링 마지막에 질문 드렸을 때는 page레이어를 활용해보라고 하셨지만 도저히 방법이 떠오르지 않아서 질문드립니다. 문제 지점은 아래입니다..
   

3. modal을 위한 상태
   modal을 위한 상태를 zustand로 관리하고 있는데 이게 좋은 판단인지 잘 모르겠습니다. 더 나은 방법이 있지 않았을까 라는 생각이 드는데 혹시 코치님이라면 어떻게 구성했을지 궁금합니다!

[stoic-park]

modal 관련 단순 상태를 공통으로 관리하는 부분이 코드가 깔끔해지고 좋은 것 같습니다!!