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

[ongsim0629]

과제의 핵심취지

• 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의 책임에 맞도록 코드가 분리가 되었나요?

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

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

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

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

심화과제

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

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

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

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

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

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

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

과제 셀프회고

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

1. 아키텍처 레이어별 책임 분리의 중요성

힌트 폴더의 구조를 분석하면서 단방향 의존성의 중요성을 처음으로 체감했다.

components/  ─────┐
                  ↓
hooks/       ────→ utils/
                  ↓
              models/

• models: 순수 계산 함수만 존재 → 아무것도 import하지 않음 → 어디서든 재사용 가능
• utils: 범용 유틸리티 함수 (formatters, validators, hooks)
• hooks: 도메인별 비즈니스 로직과 상태 관리 (useCart, useProducts, useCoupons)
• components: UI 렌더링만 담당

이렇게 하니 순환 참조가 원천적으로 불가능해지고, 각 레이어의 책임이 명확해졌습니다.

2. 도메인 중심 설계 (DDD 스타일)

각 hook이 하나의 도메인만 담당하도록 설계했다:

• useCart.ts → 장바구니 도메인의 모든 책임
• useProducts.ts → 상품 도메인의 모든 책임
• useCoupons.ts → 쿠폰 도메인의 모든 책임

코드를 수정할 때 어디를 봐야 하는지 한 번에 파악할 수 있어서 유지보수성이 크게 향상되는 것 같다.

3. 순수 함수의 위력

models/cart.ts에 모든 장바구니 계산 로직을 순수 함수로 분리했습니다:

• calculateItemTotal() - 개별 상품의 할인 적용 금액 계산
• calculateCartTotal() - 전체 장바구니 금액 계산
• getMaxApplicableDiscount() - 최대 적용 가능한 할인율 계산

이 함수들은:

• 외부 상태에 의존하지 않아 테스트하기 쉬움
• 입력만 같으면 항상 같은 결과를 반환해서 예측 가능함
• 다른 곳에서도 재사용이 자유로움

4. Props Drilling을 통한 명시적 데이터 흐름

처음에는 "props를 많이 전달하는 게 안티패턴 아닌가?"라고 생각했지만, 기본 과제에서는 의도적으로 props drilling을 사용하면서:

• 데이터 흐름이 명시적으로 드러나서 디버깅이 쉬웠고
• 컴포넌트 간 의존성이 명확해져서 어떤 데이터가 어디서 오는지 추적이 쉬웠다

(항해가 끝나면 과제 재도전 할 때 Context/Jotai로 개선할 예정)

---

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

1. Origin의 기능과 UI를 100% 그대로 유지

처음에는 AdminPage를 아코디언 UI로 만들었다가 테스트가 실패했습니다. 알고 보니 origin은 탭 구조 + 테이블 UI를 사용하고 있었습니다.

리팩토링은 파일 구조만 나누는 것이지, 기능이나 UI를 바꾸는 게 아닌데 괜한 짓 했다가 개고생했다

결국 origin의 코드를 한 줄 한 줄 분석하면서:

• 탭 구조, 테이블, 폼 레이아웃을 그대로 가져오고
• notification 시스템도 빠뜨리지 않고 구현했습니다

2. localStorage 동기화 로직

useLocalStorage hook을 만들면서 초기값 로드와 변경사항 저장을 자동화했다:

const [state, setState] = useLocalStorage<T>(key, initialValue);
// state가 변경되면 자동으로 localStorage에 저장됨

이를 통해 각 도메인 hook에서는 비즈니스 로직에만 집중할 수 있었다.

---

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

1. 심화 과제: Props Drilling 제거

Context API나 Jotai를 사용해서 불필요한 props drilling을 제거하고 싶다. 하지만 모든 props를 제거하는 게 아니라:

• 도메인 props는 남기고 (재사용성을 위해)
• 단순히 전달만 하는 props만 제거

이 기준을 명확히 세워서 "느슨한 결합"을 달성하고 싶다.

• 창준님이 던진 그 완전 심화인 것 같은 질문 : 전역 상태관리가 모든 해결책은 아니다. -> 요거는 좀 생각해봐야할 듯

2. 테스트 작성

순수 함수들(models/cart.ts, utils/validators.ts)은 테스트하기 정말 쉬울 것 같다. Unit test를 추후에 직접 작성해서 각 함수의 동작을 보장하고싶다.

3. 더 복잡한 도메인에 적용

이번에는 비교적 단순한 쇼핑몰이었지만, 더 복잡한 비즈니스 로직이 있는 프로젝트 (실무?) 에서 이 아키텍처를 적용해보고 싶다:

---

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

1. Utils vs Models의 경계

formatPrice, formatPercentage 같은 함수들을 utils에 뒀는데, 이게 맞는 건지 확신이 서지 않습니다.

• Utils: 범용적인 유틸리티 (어디서든 쓸 수 있음)
• Models: 특정 도메인의 순수 계산 로직

이 기준이 맞나요? 아니면 다른 기준이 있을까요?

2. Props Drilling, 어디까지 허용해야 할까요?

심화 과제를 하기 전이라서 깊게 고민하지는 않았지만:

• depth가 2~3단계면 props로 전달해도 괜찮나요?
• 아니면 단 한 번이라도 중간 컴포넌트를 거친다면 무조건 전역 상태로 올려야 할까요?

제 생각엔 "재사용되는 도메인 컴포넌트는 props를 받고, 단순 레이아웃 컴포넌트는 전역 상태를 쓴다"가 기준일 것 같은데 맞나요?