[12팀 김예솔] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍

[yesol123]

과제의 핵심취지

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

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

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

https://yesol123.github.io/front_5th_chapter2-2/

기본과제

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

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

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

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

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

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

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

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

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

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

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

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

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

심화과제

• 재사용 가능한 Custom UI 컴포넌트를 만들어 보기

• 재사용 가능한 Custom 라이브러리 Hook을 만들어 보기

• 재사용 가능한 Custom 유틸 함수를 만들어 보기

• 그래서 엔티티와는 어떤 다른 계층적 특징을 가지는지 이해하기

• 엔티티 Hook과 라이브러리 훅과의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• 엔티티 순수함수와 유틸리티 함수의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• UI 컴포넌트 계층과 엔티티 컴포넌트의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

✏️ 과제 셀프회고

✅ 가장 신경 쓴 부분

• 컴포넌트 내부의 복잡한 로직을 정리하고, 유틸 함수로 분리해 테스트 가능성과 재사용성을 높였습니다.
• 타입 정의 (interface)와 Props 문서화를 통해 유지보수성과 협업 가독성을 향상시켰습니다.
• AdminPage, CartPage 내에서 Set이나 Discount, Coupon 등의 작업 흐름을 함수 단위로 구분해 단순화하는 데 집중했습니다.

https://www.mermaidchart.com/raw/dba2b34f-0139-4762-9c9d-f095036ee943?theme=light&version=v0.1&format=svg

🛠️ 다시 하면 더 잘할 수 있을 것 같은 부분

• 상태 관리 로직이 여전히 컴포넌트에 섞여 있는 부분이 있어, useCart() 같은 커스텀 훅으로 분리하지 못한 점이 아쉽습니다.
• 기능 단위로 파일을 나누는 기준, 특히 utils 내 함수들을 어떤 기준으로 나누는 게 가장 명확할지를 더 고민할 수 있었을 것 같습니다.

🙋 리뷰 받고 싶은 내용

• utils 함수들을 역할별로 나누는 기준이 적절했는지 궁금합니다.
  (price, stock, discount, cart 등으로 나눈 기준이 일관성 있고 유지보수에 적절했는지?)
• toggleSetItem()처럼 범용 유틸 함수는 어느 수준까지 추상화해서 재사용하는 것이 좋을까요?
  너무 일반화되면 흐름이 모호해지는 문제가 있어 적정선을 알고 싶습니다.
• CartPage에서 상태와 액션이 섞여 있는 부분을 useCart() 훅 등으로 분리한다면 어떤 기준으로 나누는 것이 좋을지 궁금합니다.
  (예: 서버 통신 유무, 상태 저장 방식, UI 의존성 여부 등)
• ProductForm, CouponForm, ProductCard 등 Form 관련 컴포넌트의 책임을 더 나누는 기준은 어떤 것이 있을까요?
  (입력 관리만 하는 컴포넌트 vs 뷰만 담당하는 컴포넌트 등)

🌱 이번 과제에서 새롭게 알게 된 개념

• interface를 분리하여 문서화 수준의 JSDoc 스타일 주석 작성
  → 예: /** 상품 정보 */, @param, @returns 등
• toggleSetItem(set, value)와 같이 Set 자료형을 함수형으로 처리하는 방식
  → 상태를 불변하게 유지하면서 Set toggle 구현하는 함수 설계
• 유틸 함수의 책임 단위 분리
  → 계산 로직은 utils/price.ts, 상태 로직은 utils/cart.ts, 할인 관련은 utils/discount.ts로 나누는 패턴

[2Estella]

안녕하세요 예솔님!
저 이송이 입니다 :)

시간이 없어서 전체 코드를 다 보진 못했지만 소소하게 코드 리뷰 남겨보았어요 ㅎㅎ
아직 마무리는 못하신것 같지만 중간중간 학습내용이나 로직 관련 주석을 보니 바쁘신 와중에 열심히 진행하신 것 같아요! 멋찌다 육각형바퀴 김예솔!!

다음 과제도 화이팅 입니다 💖

[2Estella]

전체적으로 구조 잘 잡혀 있고, 함수형 업데이트 방식도 잘 사용하신것 같아요! 👏
몇가지 개선되면 좋을 것 같은 부분이 있어서 코드에 코멘트 달아두었습니다 ㅎㅎ

[2Estella]

저는 Product, CartItem 같은 이름은 실제 객체와 타입이 겹칠 수 있어서, ProductType, CartItemType처럼 명확하게 구분해주는 걸 선호하는 데요! 이렇게 구분하면 유지보수하거나 코드 파악하기가 더 쉬워지는 것 같아요!
사실 타입 네이밍은 회사 컨벤션이나 개인 선호도에 따라 달라서 ㅎㅎ 이런 관점도 있다~ 정도만 참고해주세요

[2Estella]

addToCart에서 수량을 늘릴 때 재고(product.stock)를 초과하지 않도록 제한해주면 어떨까요?

예를 들어, 아래처럼 수정할 수 있어요:

return latest.map((item) =>
 item.product.id === product.id
   ? { ...item, quantity: Math.min(item.quantity + 1, product.stock) }
   : item,
);

이렇게 하면 상품 재고를 초과해서 담는 걸 미리 방지할 수 있을 것 같아요 :)

[2Estella]

여기서 null을 리턴하고 .filter()로 제거하는 방식도 깔끔하지만, 수량 조건으로 직접 필터링하는 방식도 고려해볼 수 있어요!

return cart
  .map((item) =>
    item.product.id === productId
      ? { ...item, quantity: Math.min(newQuantity, item.product.stock) }
      : item
  )
  .filter((item) => item.quantity > 0);

이렇게 하면 null을 신경 쓰지 않아도 되고, 타입 단언 없이도 명확한 흐름이 유지돼서 좋을 것 같아요!