Card - FE14-Part4-Team5/reser-on-do GitHub Wiki

🧩 Card 컴포넌트 구조 설계 과정

처음에는 하나의 Card 컴포넌트에서 3가지 유형(MainCard, ReservationCard, MyExperienceCard)을 모두 대응하는 방식이 가장 좋은 구조라고 생각했어요.
하지만 주강사님께 리뷰를 요청드린 후, 제가 생각했던 “하나의 파일에서 다 처리하는 구조”는 오히려 역할이 불분명하고, 유지보수가 어려운 코드라는 생각이 들었어요

---

👇 고민했던 3가지 방식

1. 각각의 Card 컴포넌트를 완전히 분리하여 파일로 관리
2. 하나의 파일에서 모든 Card variant를 조건 분기로 처리 ← (처음엔 이게 좋은 방식이라 생각)
3. 공통 BaseCard를 만들고, 이를 확장한 3개의 카드 컴포넌트로 분리

---

❗ 왜 2번 방식은 문제가 될까?

• 하나의 컴포넌트가 너무 많은 책임을 지게 됨 (UI + 기능 + 조건 분기)
• variant가 늘어날수록 if/else, switch, clsx()가 복잡해지고 가독성이 급격히 떨어짐

---

✅ 최종 선택: 방식 1 (완전 분리형)

물론 3개의 카드에는 공통 요소 (image, title, price)가 있긴 하지만, 각 카드의 UI 구조, 버튼 기능, 사용되는 API가 모두 다르기 때문에, 공통 구조를 강제로 묶으면 유연성이 오히려 낮아지고, 나중에 새로운 카드가 등장했을 때도 대응이 어려워질 수 있어요.

예를 들어, 새로운 카드에 price가 없다면 BaseCard를 사용하는 게 오히려 방해가 될 수 있고, 한 카드에서 image(공통되는 부분)가 빠지기만 해도 전체 구조가 무너질 수 있어요. 그래서 저는 각각의 카드 컴포넌트를 완전히 분리하기로 결정했어요.

---

• MainCard
• MyExperienceCard
• ReservationCard