요구사항

• API 응답은 우안(OD), 좌안(OS) 기준으로 나뉘며 각 눈마다 다음 데이터를 포함하고 있었다.
  • 시력(UDVA)
  • 구면도수(SPH)
  • 난시도수(CYL)
• 그리고 각 항목은 다시 수술 방식별 예측 결과를 가지고 있다.

  visionComparison: {
  od: {
    udva: {...},
    sph: {...},
    cyl: {...}
  },
  os: {
    udva: {...},
    sph: {...},
    cyl: {...}
  }
  }

• 차트는 다음 조건을 만족해야 함
  • 우안과 좌안을 동일한 UI로 표시
  • 여러 수술 방식을 동시에 비교
  • 3일, 3주, 3개월 시점의 데이터를 표시
  • 수술 방식이 고정되어 있지 않음
  • UDVA는 변화 추이를 보여야 함(선 그래프)
  • SPH, CYL은 수치 비교가 가능해야 함(막대 그래프)

    공통 데이터 구조 설계

라인 차트와 바 차트가 서로 다른 데이터를 사용하면 컴포넌트 재사용이 어려워진다.

그래서 차트 종류와 관계없이 동일한 데이터 구조를 사용할 수 있도록 설계했다.

export type VisionValue = {
  "3days": number | null;
  "3weeks": number | null;
  "3months": number | null;
};

export type SurgeryVision = {
  LASIK?: VisionValue;
  SMILE?: VisionValue;
  LASEK?: VisionValue;
  ICL?: VisionValue;
};

export type VisionComparisonItem = {
  udva: SurgeryVision;
  sph: SurgeryVision;
  cyl: SurgeryVision;
};

• 실제 API 응답은 다음과 같은 형태이다.

  {
  LASIK: {
    "3days": 0.9,
    "3weeks": 1.0,
    "3months": 1.2
  },
  
  SMILE: {
    "3days": 1.0,
    "3weeks": 1.1,
    "3months": 1.2
  }
  }

• 수술 방식은 환자마다 달라질 수 있기 때문에 모든 속성을 Optional로 구성하였다.

  ChartPanel을 활용한 공통 UI 구성

• UDVA는 Line Chart, SPH와 CYL은 Bar Chart로 표현해야 했지만 카드 UI와 범례는 모두 동일했다.

• 그래서 공통 레이아웃을 담당하는 ChartPanel 컴포넌트를 만들고, 차트 종류만 props로 전달하도록 구성했다.

  <ChartPanel
  title="시력"
  data={data.udva}
  mode="line"
  />
  

## Recharts용 데이터 가공
- API 응답 구조를 그대로 사용할 수는 없었다.
- Recharts는 시계열 데이터를 배열 형태로 전달해야 하기 때문
- 기존 API 응답

{ "LASIK": { "3days": 1, "3weeks": 1, "3months": 1 }, "SMILE": { "3days": 1, "3weeks": 1, "3months": 1.2 } }

````

• 이런 식으로 가공해야함

  [
  {
    label: "3일",
    LASIK: 0.9,
    SMILE: 1.0,
    LASEK: 0.8,
    ICL: 0.95
  },
  {
    label: "3주",
    LASIK: 1.0,
    SMILE: 1.1,
    LASEK: 0.9,
    ICL: 1.0
  },
  {
    label: "3개월",
    LASIK: 1.2,
    SMILE: 1.2,
    LASEK: 1.1,
    ICL: 1.1
  }
  ]

• 이를 위해 렌더링 전에 Recharts에서 사용할 수 있는 형태로 데이터를 가공함

const chartData = [
  {
    label: "3일",
    LASIK: data.LASIK?.["3days"],
    LASEK: data.LASEK?.["3days"],
    SMILE: data.SMILE?.["3days"],
    ICL: data.ICL?.["3days"],
  },
  ...
];

수술 방식에 따른 동적 시리즈 생성

• 어떤 환자는 LASIK과 SMILE만 추천될 수 있고,
• 다른 환자는 네 가지 수술 방식이 모두 제공될 수도 있다. => 데이터에 존재하는 수술 방식만 추출하여 동적으로 생성하도록 구현하였다.

export type SurgeryType = "LASIK" | "LASEK" | "SMILE" | "IC

const visibleTypes =
  Object.keys(data) as SurgeryType[];

 {visibleTypes.map((type) => {
   const chip = chipList.find((item) => item.name === type);

   if (!chip) return null;

    return (
      <Line
         key={type}
         type="linear"
         dataKey={type}
         stroke={chip.color}
         strokeWidth={3}
         dot={false}
         activeDot={false}
         isAnimationActive={false}
     />
     );
    })}

• 이렇게 구현하면
  • LASIK만 있는 경우
  • LASIK + SMILE인 경우
  • 모든 수술 방식이 있는 경우
• 모두 하나의 컴포넌트로 처리할 수 있다.

동일한 구조로 Bar Chart 구현

• 시력(UDVA)은 시간에 따른 변화 추이를 확인하는 것이 중요했기 때문에 LineChart를 사용하였다.
• 반면 구면도수(SPH)와 난시도수(CYL)는 수술 방식별 수치를 비교하는 것이 목적이었기 때문에 BarChart를 사용하였다.
• 하지만 데이터 구조는 동일하게 유지하였다.

  <ChartPanel
  title="구면도수"
  data={data.sph}
  mode="bar"
  />
  

```

요구 사항

• 사용자가 충전 금액 선택
• 주문 생성 API 호출
• NICEPAY 카드 결제 진행
• 결제 성공 시 백엔드 검증 후 결과 페이지 이동
• 결제 실패 시 실패 페이지로 이동

1. 결제 금액 선택

• 먼저 사용자가 충전 금액을 선택할 수 있도록 구현했다.
• 백엔드에서 충전 상품 목록을 조회한 뒤 버튼 형태로 렌더링하였다.

  const [selected, setSelected] = useState<number | null>(null);
  const [selectedIdx, setSelectedIdx] = useState<number | null>(null);

• 선택된 상품의 가격과 상품 ID를 상태로 관리하였다.

2. 주문 생성 API 호출

• 실제 결제 요청 전에 백엔드에서 주문 정보를 생성한다.

  const { data: orderInfo } = useQuery({
  queryKey: ["productOrder", selectedIdx],
  enabled: open && selectedIdx !== null,
  queryFn: () =>
    getAdjustmentOrder({
      productInfoIdx: selectedIdx!,
    }),
  });
  

- 주문 생성 API를 통해 다음 정보를 받아온다.
    - orderId
    - amount
- NICEPAY는 결제 요청 시 orderId가 반드시 필요하기 때문에 사전에 생성해두어야 한다.
### 3. NICEPAY 스크립트 로드
- NICEPAY는 외부 스크립트를 통해 결제 창을 제공한다.
- Next.js에서는 Script 컴포넌트를 사용하여 로드했다.
- 스크립트가 로드되지 않은 상태에서 결제를 시도하면 오류가 발생할 수 있으므로 별도의 상태값으로 관리했다.