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

[Thomas97-J]

과제의 핵심취지

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

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

과제 셀프회고

배포 주소 : 심화과제 / https://thomas97-j.github.io/front_7th_chapter3-2/

이번 과제는 다음과 같은 순서로 작업을 진행했다.

1. 훅 분리
2. 훅에서 사용하는 헬퍼 함수 추가/ 유틸 함수 추가
3. 컴포넌트 분리 - 이때 가장 작은 컴포넌트부터 교체
4. 기능 단위의 컴포넌트 분리
5. 재귀적으로 컴포넌트 분리
6. 전역 상태 관리를 추가하여 프롭스 드릴링 해결

이런 순서대로 작업을 진행한 이유는 다음과 같다.

1. 뷰를 분리할 때 해당 뷰에서만 사용되는 로직은 함께 이동해야 한다. (컴포지션 패턴을 위해서)
   a. 이때 로직을 먼저 리팩토링하지 않으면 뷰를 분리할 때 관련 로직을 파악하기 어려워지고, 실수의 가능성이 높아진다.
   b. 때문에 가장 먼저 훅을 분리해서 엔티티들을 도메인 별로 분리하고, 해당 훅에서 사용되는 헬퍼 함수와 공통 유틸 함수를 구분하는 것이 효율적이다.
2. 컴포넌트를 분리할 때, UI컴포넌트를 먼저 분리한 이유는, 컴포넌트가 크게 뭉쳐져 있을때 공통적으로 사용하는 코드의 파악이 쉽기 때문이다.
3. 공통되는 스타일 등을 UI 컴포넌트로 분리한 뒤, 기능 단위로 컴포넌트를 가장 큰 단위로 나눈다.
   a. 나누어진 컴포넌트를 다시 기능 단위로 가장 큰 단위로 나눈다. 이렇게 진행해야 상위 컴포넌트 - 하위 컴포넌트 순으로 폴더 구조를 작성하기 쉬워진다.

프롭스 드릴링에 시달려 보는걸 권장하는 기본 과제의 취지에 맞게 기능별로/ui별로 컴포넌트를 최대한 분리한 다음 프롭스를 내려보냈다. 언제부턴가 전역상태관리를 당연하게 사용해서, 훅으로 분리한 로직을 다른 컴포넌트에서 사용하는 일이 무척 당연한 일로 여겨졌는데, 이번 과제를 하며 새삼 탄스택 쿼리도 전역적으로 공유되는 서버 상태라는 것을 되새길 수 있었다. 기껏 분리한 훅이 컴포넌트 상단에서만 사용된 뒤 다시 사용될 일이 없었기 때문이었다.
또 전역 상태를 사용하지 않으니 훅들 사이에서 의존하는 값을 사용하기 위해 상태를 서로 props로 전달하는 형태를 취해야만 했던 것도 그동안 잊고 있었던 전역상태관리의 중요성을 다시 느끼게 해 주었다.

또한 보통 유틸을 제작하거나 UI 컴포넌트를 제작할 때, 약간의 도메인 정보가 들어가는 것에 대해 큰 생각을 하지 않고 코드를 작성했는데, 이를 엄격하게 나누고 격리하는 과정이 무척 흥미로웠다. 이렇게 분리된 로직으로 계층 구조를 생각하는 것이 훨씬 더 직관적으로 느껴졌다. 그동안 내가 작성하는 코드들의 계층 구조를 명확하게 설명하지 못하겠다고 생각한 이유가 도메인 정보들이 엄격한 격리 없이 여기저기 퍼져있었기 때문이라는 것을 알 수 있었다.

이후 심화과제를 진행하며 도메인 관련 훅을 모두 jotai를 활용해 전역 상태 관리로 전환했다. 이 작업은 많은 부분을 ai를 사용했다. 기본 과제를 진행하며 프롭스 드릴링이 과도한 부분을 정리하고, 각 스탭을 확인하며 진행한 결과 큰 문제 없이 작업이 금새 마무리 되었다. 유일하게 문제가 발생한 것이 notifications와 관련된 테스트였는데, 전역상태가 초기화 되지 않아 발생한 문제였다. 이는 크게 중요하지 않은 부분이라 생각해, 테스트 코드 내부에 전역상태를 초기화 하는 로직을 추가했다.

cart, products, coupons, 거기에 이 훅들에서 의존하는 notifications까지 전역 상태 관리로 전환하자, 원래 내가 자주 사용하고는 하던 패턴대로 훅을 사용할 수 있었다. 각 훅들 사이에 엔티티들을 props로 전달하지 않게 되자 불필요한 훅 호출이 줄어들었고, 코드가 직관적으로 변함을 느낄 수 있었다. 또한 전역상태관리가 들어가자 부모에서 자식으로 내려주는 프롭스가 절반 이하로 줄어드는 것을 느낄 수 있었다. 또 어드민과 카트 페이지가 상단에서 값을 내려받지 않아, 이를 별도 라우팅으로 분리하는 등의 작업이 필요할 때 바로 컴포넌트들을 옮길 수 있게 되었다.

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

작성된 코드의 계층에 대해 이해하는 능력을 조금 키울 수 있게 된 것 같다. 또 어떻게 해야 코드의 계층을 나누고 격리하는지도 감을 조금 잡은 것 같다.

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

컴포넌트의 리팩토링은 결국 비슷한 형태로 귀결될 것이라 생각했다. 때문에 어떤 순서로 작업을 진행하는것이 효율적일지 계획을 작성하고 작업을 들어가는 것을 목표로 했다. 평소 리팩토링을 진행할 때 크게 의식하지 않고 진행하던 흐름을 미리 적고 어떤것이 더 효율적인지 고민해 보았는데, 계획대로 작업이 진행된 것 같아 마음에 들었다.

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

사내 코드리뷰를 할 때 이렇게 작성하면 안돼지 않아요? 대신 왜 안되는지, 왜 도메인 정보를 이 컴포넌트에서 빼야하는지 오밀조밀하게 따져보고 싶다.

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

기본과제를 진행하면서 useValidate에 해당하는 훅은 전역상태관리 없이는 구현이 큰 의미가 없을 것 같아 넘어갔습니다. (노티피케이션 관련해서 프롭스로 전달하며 사용하고 싶지 않았습니다.) 이후 심화과제를 진행할 때 useValidate 훅을 넣는 것을 고려해 보았는데, 쿠폰폼이나 프로덕트 폼의 검증은 결국 다른 엔티티를 대상으로 하고 있어, 엔티티를 업데이트 하는 훅을 전달하는 방향으로 구현해야 될 것 같은 느낌이라 결국 컴포넌트 안에서 직접 검증을 진행하는것이 더 효과적이지 않나? 싶은 생각이 들어 구현하지 않게 되었습니다.

useValidate가 사용된다면 어떤 형태로 구현되고, 사용될 수 있을지 궁금합니다.