과제 링크

https://geonhwiii.github.io/front_6th_chapter2-2/

과제의 핵심취지

• React의 hook 이해하기
• 함수형 프로그래밍에 대한 이해
• 액션과 순수함수의 분리

과제에서 꼭 알아가길 바라는 점

• 엔티티를 다루는 상태와 그렇지 않은 상태 - cart, isCartFull vs isShowPopup
• 엔티티를 다루는 컴포넌트와 훅 - CartItemView, useCart(), useProduct()
• 엔티티를 다루지 않는 컴포넌트와 훅 - Button, useRoute, useEvent 등
• 엔티티를 다루는 함수와 그렇지 않은 함수 - calculateCartTotal(cart) vs capaitalize(str)

기본과제

• Component에서 비즈니스 로직을 분리하기

• 비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기

• 뷰데이터와 엔티티데이터의 분리에 대한 이해

• entities -> features -> UI 계층에 대한 이해

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• 특정 Entitiy만 다루는 함수는 분리되어 있나요?

• 특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?

• 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

• 이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.

• 어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.

• Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.

• Context나 Jotai를 사용해서 전역상태관리를 구축했나요?

• 전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?

• 도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?

• 전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?

과제 셀프회고

고민 Point?

• 주제가 함수형 프로그래밍이었는데, 고민할 시간이 없었습니다...!

• AI를 안쓰니까 일단 리팩토링 시간이 상대적으로 오래걸렸습니다.

• 목표는 FSD를 떠나서, entities와 같은 각 모델들을 잘 구분해서 분리하는 것에 집중하였습니다.

• 처음에 분리하다보니 무작정 hooks로 분리하는 자신을 발견하게 되었고,

• 정신차리고 예시를 참고해서 기능별 entities에 집중해서 model 분리에 집중하였습니다

느낀점 및 리뷰 요청

• 과제다보니 client에서 상태를 다 다루니까, server에서 데이터를 다루는게 코드적으로 이점이 많다는걸 알게되었습니다.
• 의존성 관계에 따라 Provider를 아래로 내리는 방식을 사용했습니다.

    export function AppProvider({ children }: AppProviderProps) {
        return (
          <NotificationProvider>
            <ProductProvider>
              <CouponProvider>
                <CartProvider>{children}</CartProvider>
              </CouponProvider>
            </ProductProvider>
          </NotificationProvider>
        );
      }

• Flow상으로 현업에서도 자주 이런방식으로 구현이 되는데, 아쉬운 부분은 각 Provider가 상위 Provider를 참조하다보니 좋은 구조라고는 생각은 안됩니다.
• 이런 부분을 개선하기 위해 zustand, jotai등의 상태 관리 라이브러리를 사용하거나, 내부에서 context를 직접 사용하지 않고 의존성을 주입하는 것이 좋을 것이라 생각은 듭니다.

[질문] Context API를 사용할 때 보통 이런 구조로 Provider를 연계해서 사용하는 경우가 자주 나오는데, 각 Provider가 내부적으로 외부 Context를 덜 참조되게 구성할 수 있을까요?