feat: 메뉴/예약금 type 및 mock데이터/hooks 추가

[jjjsun]

💡 개요

고객 메뉴 예약과정에서 메뉴선택UI추가/메뉴 총액 기준으로 예약금(사장님 설정 10~50%)이 계산되도록 하기 위해
공용 type/util 및 API 연동전 사용할 mock/hooks를 추가했습니다.

🔢 관련 이슈 링크

• Closes [feat] 메뉴선택과 예약금률 적용을 위한 공용 타입/유틸/mock 기반 추가 #34

💻 작업내용

• 메뉴/예약금 기능개발을 위해서 공용 type을 정의 (types/menus.ts, types/payment.ts)
• 예약금 정책 변경 따라 기존 식당 타입/mock 일부 수정 (types/restaurant.ts, mock/restaurants.ts)
• 메뉴 총액/예약금 계산 유틸 추가 (utils/menu.ts, utils/payment.ts)
• 백엔드 API연동전까지 사용할 mock데이터와 mock데이터 접근 hooks 추가 (mock/menus.ts, mock/restaurantSetting.ts, hooks/useDepositRate.ts, hooks/useMenus.ts)

📌 변경사항PR

• FEAT: 새로운 기능 추가
• FIX: 버그/오류 수정
• CHORE: 코드/내부 파일/설정 수정
• DOCS: 문서 수정(README 등)
• REFACTOR: 코드 리팩토링 (기능 변경 없음)
• TEST: 테스트 코드 추가/수정
• STYLE: 스타일 변경(포맷, 세미콜론 등)

🤔 추가 논의하고 싶은 내용

• 사장님 flow의 내가게관리/메뉴관리 구현시에, 이번 PR의 공용 type 기준으로 연동 부탁드립니

✅ 체크리스트

• 브랜치는 잘 맞게 올렸는지
• 관련 이슈를 맞게 연결했는지
• 로컬에서 정상 동작을 확있했는지
• 충돌이 없다(또는 브랜치에서 충돌 해결 후 PR 업데이트 완료)

Summary by CodeRabbit

새로운 기능

• 예약 시 메뉴 선택 및 주문 기능이 추가되었습니다.
• 선택한 메뉴의 총 가격 계산 기능이 추가되었습니다.
• 예약금 계산 기능이 추가되었습니다.
• 레스토랑별 예약금 비율 설정이 지원됩니다.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

메뉴 선택과 예약금 계산을 위한 공용 타입, 유틸 함수, 목(mock) 데이터, 그리고 React 훅을 추가합니다. MenuCategory, MenuItem, SelectedMenu와 DepositRate 타입을 정의하고, 계산 함수들과 데이터 접근 훅을 제공합니다.

Changes

Cohort / File(s)	Summary
타입 정의 src/types/menus.ts, src/types/payment.ts, src/types/restaurant.ts	MenuCategory, MenuItem, SelectedMenu, DepositRate 타입 추가. Restaurant, ReservationDraft, PaymentPolicy 업데이트하여 메뉴 선택과 예약금 정책 지원.
목 데이터 src/mock/menus.ts, src/mock/restaurantSetting.ts, src/mock/restaurants.ts	mockMenusByRestaurantId와 mockDepositRateByRestaurantId 추가. restaurants.ts에서 depositAmount 필드 제거.
유틸 함수 src/utils/menu.ts, src/utils/payment.ts	calcMenuTotal로 선택된 메뉴의 총액 계산, calcDeposit로 예약금 금액 계산.
React 훅 src/hooks/useDepositRate.ts, src/hooks/useMenus.ts	useDepositRate로 식당별 예약금률 조회, useMenus로 활성 메뉴 필터링.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

타입에 목 데이터, 유틸까지 🍲
예약금 계산하고 메뉴도 골라, 📋
팀 공용 기초 완성! 🎉
훅으로 쉽게 가져가고,
앞으로 나아갈 발판 다졌네 ✨

---

리뷰 코멘트

전반적으로 잘 구성되었습니다! 기초 구조가 튼튼해서 추후 API 연동 시 교체하기 좋을 것 같습니다. 몇 가지 확인 사항을 드립니다:

1️⃣ Type Safety — DepositRate 확장성

현재 DepositRate가 0.1 | 0.2 | 0.3 | 0.4 | 0.5로 고정되어 있는데, 미래에 새로운 예약금률이 추가될 가능성이 있다면 고민해 볼 점입니다.

// 대안: 더 확장 가능한 구조 (선택사항)
export type DepositRate = number; // 0 ~ 1 범위

// 또는 명시적으로 유효성 검증
export type DepositRate = 0.1 | 0.2 | 0.3 | 0.4 | 0.5;
export const VALID_DEPOSIT_RATES = [0.1, 0.2, 0.3, 0.4, 0.5] as const;

2️⃣ Utils — Rounding 방식 확인

calcDeposit에서 반올림 처리가 필요한데, 현재 구현을 확인하고 싶습니다. 예를 들어:

// 만약 Math.round를 쓰신다면
export function calcDeposit(totalPrice: number, rate: DepositRate): number {
  return Math.round(totalPrice * rate * 100) / 100; // 소수점 2자리
}

금융 계산이므로 일관된 반올림 규칙이 명시되면 좋을 것 같습니다.

3️⃣ Mock Data — 기본값 처리

useDepositRate와 useMenus에서 없는 restaurantId 접근 시 동작:

// 현재: mockDepositRateByRestaurantId[restaurantId] ?? 0.3
// 문제: 실제 API 연동 시 restaurantId 오류를 놓칠 수 있음

// 대안: console.warn이나 로깅
export function useDepositRate(restaurantId: string) {
  return useMemo(() => {
    const rate = mockDepositRateByRestaurantId[restaurantId];
    if (!rate) {
      console.warn(`[useDepositRate] restaurantId not found: ${restaurantId}`);
    }
    return { rate: rate ?? 0.3 };
  }, [restaurantId]);
}

4️⃣ Accessibility 고려

목 데이터의 한글 메뉴명(김치찌개, 된장찌개 등)은 좋지만, 추후 imageUrl이나 description이 비어있을 경우 UI에서 대체 텍스트(alt text) 처리를 잊지 않으시면 좋겠습니다.

5️⃣ performance — useMemo 의존성

현재 구현이 좋지만, restaurantId 외에 다른 상태 변화가 생길 수 있으니 의존성 배열을 정확히 유지해주세요.

---

전반적으로 공용 기초 작업이 깔끔하게 진행되었습니다! 다음 단계(UI 구성, 라우팅, API 연동)에서 이 기초들이 잘 활용될 것 같습니다. 👍

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR 제목은 주요 변경사항(메뉴/예약금 타입, mock데이터, hooks 추가)을 명확하고 간결하게 요약하고 있습니다.
Description check	✅ Passed	PR 설명이 템플릿 구조를 따르며, 개요, 관련 이슈, 작업내용, 체크리스트를 모두 포함하고 있습니다.
Linked Issues check	✅ Passed	PR의 모든 변경사항이 이슈 #34의 요구사항을 충족합니다. 공용 타입, 유틸, mock 데이터, hooks 모두 구현되었습니다.
Out of Scope Changes check	✅ Passed	PR의 모든 변경이 이슈 #34의 범위 내에 있으며, 범위를 벗어나는 변경사항이 없습니다.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/shared-menu-schema

Tip

🧪 Unit Test Generation v2 is now available!

We have significantly improved our unit test generation capabilities.

To enable: Add this to your .coderabbit.yaml configuration:

reviews:
  finishing_touches:
    unit_tests:
      enabled: true

Try it out by using the @coderabbitai generate unit tests command on your code files or under ✨ Finishing Touches on the walkthrough!

Have feedback? Share your thoughts on our Discord thread!

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/types/restaurant.ts (1)

48-56: ⚠️ Potential issue | 🟠 Major

draft.payment 필드 제거로 인한 런타임 에러 발생

ReservationDraft에서 payment 필드가 완전히 제거되었는데, 두 컴포넌트에서 여전히 이 필드를 참조하고 있어요. 이대로 머지되면 앱이 동작하지 않을 거예요.

문제 위치:

• PaymentModal.tsx 39번 줄: draft.payment.depositAmount 접근 불가
• ReservationConfirmModal.tsx 104-106번 줄: draft.payment.depositAmount, draft.payment.depositRate 접근 불가

개선 방안:
결제 정보가 draft가 아닌 restaurant prop에 있으므로, 컴포넌트들을 수정해야 해요. 예를 들어:

// PaymentModal.tsx - before
const amount = useMemo(() => draft.payment.depositAmount, [draft.payment]);

// PaymentModal.tsx - after (restaurant.paymentPolicy가 있다고 가정)
const amount = useMemo(() => restaurant.paymentPolicy.depositAmount, [restaurant.paymentPolicy]);

ReservationDraft에 다시 payment 필드를 추가하는 방안도 있지만, 현재 구조상 restaurant에서 가져오는 게 더 적절해 보여요.

🧹 Nitpick comments (4)

src/mock/restaurantSetting.ts (1)

3-6: 주석 처리된 코드 정리 고려

주석 처리된 "2": 0.3 항목이 있는데, mock 데이터로 활용할 계획이면 주석을 해제하고, 불필요하면 제거하는 게 깔끔할 것 같아요. 테스트 시 여러 케이스를 커버하려면 다양한 식당 데이터가 있으면 좋겠네요.

💡 mock 데이터 확장 예시

 export const mockDepositRateByRestaurantId: Record<string, DepositRate> = {
   "1": 0.5,
-  //   "2": 0.3,
+  "2": 0.3,
+  "3": 0.1,
 };

src/hooks/useDepositRate.ts (1)

5-10: useMemo 사용 여부 검토

mockDepositRateByRestaurantId[restaurantId]는 단순한 객체 조회라서 useMemo 없이도 성능에 영향이 거의 없어요. 현재 mock 데이터가 모듈 레벨 상수이기 때문에 메모이제이션이 필수는 아닙니다.

다만, 향후 API 연동 시 비동기 호출로 변경될 가능성이 높으니 현재 구조를 유지하는 것도 괜찮아요. 단순화하고 싶다면 아래처럼 변경할 수 있습니다.

💡 단순화 예시 (선택사항)

 export function useDepositRate(restaurantId: string) {
-  const rate: DepositRate = useMemo(() => {
-    return mockDepositRateByRestaurantId[restaurantId] ?? 0.3;
-  }, [restaurantId]);
+  const rate: DepositRate = mockDepositRateByRestaurantId[restaurantId] ?? 0.3;

   return { rate };
 }

As per coding guidelines: src/hooks/**: 의존성 배열(useEffect) 정확성, 불필요한 re-render/메모이제이션 남발 금지.

src/utils/menu.ts (1)

3-9: 존재하지 않는 menuId 처리 확인 필요

priceMap.get(s.menuId) ?? 0으로 존재하지 않는 메뉴를 0원으로 처리하고 있어요. 의도적인 설계라면 괜찮지만, 잘못된 menuId가 전달됐을 때 조용히 무시되면 버그를 놓칠 수 있어요.

개발 환경에서라도 경고를 남기거나, 엄격한 처리가 필요하다면 에러를 던지는 방식도 고려해 볼 수 있습니다.

💡 개발 환경 경고 추가 예시

 export function calcMenuTotal(menus: MenuItem[], selected: SelectedMenu[]) {
   const priceMap = new Map(menus.map((m) => [m.id, m.price]));
   return selected.reduce(
-    (sum, s) => sum + (priceMap.get(s.menuId) ?? 0) * s.quantity,
+    (sum, s) => {
+      const price = priceMap.get(s.menuId);
+      if (price === undefined) {
+        console.warn(`calcMenuTotal: menuId "${s.menuId}" not found`);
+        return sum;
+      }
+      return sum + price * s.quantity;
+    },
     0,
   );
 }

src/hooks/useMenus.ts (1)

5-11: 불필요한 useMemo 제거 추천드려요.

이 코드의 두 연산 모두 매우 가벼워요:

• 객체 조회(mockMenusByRestaurantId[restaurantId])는 O(1) 연산
• 배열 필터링도 간단한 작업

React 공식 가이드에 따르면 useMemo는 계산이 눈에 띄게 느릴 때만 사용할 가치가 있어요. 위 경우엔 그렇지 않으니, 메모이제이션을 제거하면 코드가 더 명확해지고 팀의 가이드(불필요한 메모이제이션 지양)에도 맞습니다.

♻️ 제안 코드

 export function useMenus(restaurantId: string) {
-  const menus: MenuItem[] = useMemo(() => {
-    return mockMenusByRestaurantId[restaurantId] ?? [];
-  }, [restaurantId]);
-
-  const activeMenus = useMemo(() => menus.filter((m) => m.isActive), [menus]);
+  const menus: MenuItem[] = mockMenusByRestaurantId[restaurantId] ?? [];
+  const activeMenus = menus.filter((m) => m.isActive);
 
   return { menus, activeMenus };
 }