[6팀 김소리] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계

[milmilkim]

배포 링크 !!

advanced
https://milmilkim.github.io/front_7th_chapter3-2/
basic
https://milmilkim.github.io/front_7th_chapter3-2/index.basic.html

과제의 핵심취지

• 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는 잘 제거했나요?

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

과제 셀프회고

과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?

함수형 프로그래밍에서 말하는 액션, 계산, 데이터의 개념을 알 수 있어서 좋았다. 그리고 부수효과에 대해서도 좀 더 구체적으로 알 수 있게 되었다.
리액트에서의 useEffect의 경우, 이것은 클래스형 컴포넌트의 생명주기 대신 사용할 수 있지만 그 자체로 생명주기는 아니며 부수효과를 다루기 위한 훅이라는 얘기를 많이 봤었는데 그래서 '부수 효과'가 뭐지? 하는 막연한 생각만을 가지고 있었지만 이 기회에 한걸음 더 가까워지지 않았나 싶다.

평소에 컴포넌트를 쪼개는 기준은 그냥 '내가 보기 좋은가?'정도였다. (내가 편하게 유지보수 할 수 있으면 그게 잘 만든 게 아닌가 하는 생각 😅) 막연히 비즈니스로직과 UI가 분리되어야 한다고 하는데 그냥 개발을 하다보면 자연스럽게 그런 방향으로 흘러가는 것 같았다. 정해진 원칙이 있는 것은 아니었다.
과제를 함으로써, 왜 그런 결론에 도달하였는지 알 수 있었다.

리액트의 '추구미'라는 것을 알아볼 수 있는 좋은 경험이었다.

그리고 그냥 내 맘대로, 감으로 익힌 느낌으로 개발을 할 때는 다른 작업자에게 어떤 방향으로 개발해야 하는지 명확한 방법과 이유를 설명하지 못했었는데, 언어를 알게 되어서 도움이 되었다.

basic을 마치고 advanced로 넘어가며, 이 지긋지긋한 props drilling을 감내하였으니 이제 context로 전환하는 작업만 더해서, 최종적으로 코드를 보기 좋게 정리하려 했다.
그런데 Q&A라든가 디스코드에서의 대화를 보다보니 좀 더 생각을 하게 되는 부분들이 있었다.

하나는 상태 관리에 대한 것이었는데 나는 Context API를 그저 props drilling을 없애기 위한 목적으로만 사용할 생각이었다.
그런데 'Context는 Props drilling을 해결하기 위한 것이 아니다'라는 말을 보게 되고, 일단 그 말도 헷갈렸지만 그래서 상태관리는 무엇인가 하는 근원적인 의문에 빠져들었다.

그 의문에 대해서는 테오의 멘토링 시간에 어느 정도 답을 찾을 수 있었고 (감사합니다) 이 과제상에서는 그냥 단순하게 사용했다.
원래같았더라면 API를 사용하여 조회하는 부분을 클라이언트에서 다루어야 했기에 이런 구조가 되었다.

또 디렉토리 구조에 대해 고민하는 분들도 많았다. 물론 나도 실무에서는 항상 너무너무 고민을 많이 하는 부분이다. 하지만 과제에서는 컴포넌트를 나누는 것에만 집중하고 디렉토리 구조는 깊은 고민은 하지 않고 넘어갔다. 경험상 프로젝트 규모가 작을 땐 굳이 depth가 깊어질 필요가 없다. 더 시도해봐도 좋을 것 같지만 그것은 다음 과제에 있으니! 고민은 여기까지만 하고 넘어갔다.

이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?

AI에 너무 의존하지 않으려 했다. 그래서 초반엔 커서에 자동 완성 기능만 켜놓고 수제로 리팩토링을 진행하였다.
큰 페이지 범위부터 컴포넌트를 분리하고 모든 프롭스를 다 뚫었다. 그리고 순수 함수를 작성하고 훅을 만든 후 원래의 기능이 바뀌지 않게 신경 쓰면서 기존 코드를 수정했다. (테스트코드가 있어서 행복하다.) 그렇게 과제를 진행하다가 후반에 누가 해도 똑같은 결과가 나올만한 지점에는 체력이 부족해서 ai를 마저 사용하였다.

그리고 useEffect를 최대한 걷어내고자 했다. useEffect를 지양하는 이유는 여러 가지가 있지만, 가장 큰 이유는 의존성 배열로 인하여 디버깅 난이도가 커지고, 예상하지 못한 버그가 생길 수 있기 떄문이다. (완전히 같은 개념은 아니지만) 회사에서 뷰 개발을 할 때도 이유 없이 watch를 쓰면 팀장님께 혼났기 때문에 그 습관이 이어진 것이라 할 수 있다.

이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!

앞으로 새로 개발을 할 일이 있으면 이번 과제를 통해 배운 원칙을 잘 적용해 보고 싶다. 다른 작업자들도 같은 방식으로 작업할 수 있게 가이드를 줄 수 있으면 더 좋을 것이다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

useLocalStorage

export function useLocalStorage<T>(
  key: string,
  initialValue: T
): [T, (value: T | ((val: T) => T)) => void] {
  const [value, setValue] = useState<T>(() => {
    const item = localStorage.getItem(key);
    return item ? JSON.parse(item) : initialValue;
  });

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(value));
  }, [key, value]);

  return [value, setValue];
}

이 훅은 짧고 간단한 듯 하여 useEffect 기반으로 구현했습니다.
다만 value setter에 localStorage 업데이트를 포함시키면 useEffect를 제거할 수도 있습니다.
어떤 방식이 더 React적일까요?