왜 나는 이제 any를 쓰지 않기로 했는가

let obj: any = { x: 0 };
 
obj.foo();           // 에러 없음
 
obj();               // 에러 없음
 
obj.bar = 100;       // 에러 없음
 
obj = "hello";       // 에러 없음
 
const n: number = obj; // 에러 없음

// eslint-disable-next-line @typescript-eslint/no-explicit-any
const data = res as any;

<CommonGrid
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  rowData={list as any[]}
/>

// 1. 데이터 타입 정의 (e.g., 상품 정보)
interface Product {
  id: number;
  name: string;
  price: number;
}
 
// 2. 제네릭을 받는 Grid 컴포넌트 정의
// 제네릭 T는 rowData 배열에 들어갈 데이터의 타입을 의미
interface GridProps<T> {
  rowData: T[];
}
 
// T는 최소한 'id'를 포함하는 객체여야 함을 명시
function CommonGrid<T extends { id: number }>({ rowData }: GridProps<T>) {
  return (
    <table>
      <tbody>
        {rowData.map((row) => (
          // 제네릭 T 덕분에 'row' 객체의 속성을 타입스크립트가 정확히 인지
          // 따라서 'row.id', 'row.name', 'row.price' 등에 안전하게 접근할 수 있다.
          <tr key={row.id}>
            <td>{row.id}</td>
            {/* <td>{row.name}</td> */}
            {/* <td>{row.price}</td> */}
          </tr>
        ))}
      </tbody>
    </table>
  );
}
 
// 3. 부모 컴포넌트에서의 사용 비교
function ProductListPage() {
  // 서버로부터 받아온 상품 목록 데이터라고 가정합니다.
  const productList: Product[] = [
    { id: 101, name: '노트북', price: 1500000 },
    { id: 102, name: '무선 마우스', price: 35000 },
  ];
 
  return (
    <div>
      <h3>Before: any로 타입을 무력화한 경우</h3>
      {/* 'as any[]'를 쓰는 순간, productList가 'Product[]'라는
        중요한 정보를 잃게 된다. CommonGrid 컴포넌트 내부에서는 
        'row'가 무슨 타입인지 전혀 알 수 없어, 없는 속성에 접근해도
        런타임에 가서야 문제가 발생한다.
      */}
      <CommonGrid rowData={productList as any[]} />
 
      <hr />
 
      <h3>After: 제네릭 타입을 명시하여 안전성을 확보한 경우</h3>
      {/* <Product> 라고 명시해주면, CommonGrid는
        'rowData'가 'Product[]' 타입임을 명확히 알게 된다.
        결과적으로 컴포넌트 내부에서 완벽한 타입 추론과 보호를 받게 된다.
      */}
      <CommonGrid<Product> rowData={productList} />
    </div>
  );
}

// 1. 데이터 타입 정의
interface Product {
  id: number;
  name: string;
  price: number;
}
 
// 2. API 응답 데이터라고 가정
const response = {
  data: {
    products: [
      { id: 101, name: '노트북', price: 1500000 },
      { id: 102, name: '무선 마우스', price: 35000 },
    ],
  },
};
 
// Before: 타입 선언이 없는 경우
// 만약 response.data.products가 undefined이면 'listBefore'는 'any[]'로 추론될 수 있고,
// 이후 코드에서 타입 안정성을 잃게 됩니다.
const listBefore = response?.data?.products ?? [];
 
// After: 변수에 타입을 명시적으로 선언한 경우
// 'productList'는 항상 'Product[]' 타입임이 보장됩니다.
// 만약 'response.data.products'의 구조가 'Product'와 다르면
// 할당하는 시점에서 바로 타입 에러가 발생하여 실수를 방지합니다.
const productList: Product[] = response?.data?.products ?? [];

function processValue(value: unknown) {
  // 에러 발생: 'value' is of type 'unknown'.
  // 타입을 확인하기 전에는 어떤 속성이나 메서드도 사용할 수 없다.
  // value.toUpperCase();
 
  // 해결: 타입 가드(Type Guard)를 통해 타입을 좁힌다.
  if (typeof value === 'string') {
    // 이 블록 안에서 'value'는 'string' 타입임이 보장된다.
    console.log(value.toUpperCase());
  } else if (typeof value === 'object' && value !== null && 'message' in value) {
    // 복잡한 객체에 대한 타입 검사도 가능하다.
    console.log((value as { message: string }).message);
  }
}
 
processValue("hello world"); // "HELLO WORLD"
processValue({ message: "This is an object" }); // "This is an object"
processValue(123); // 아무 일도 일어나지 않고 안전하게 넘어감

// 숫자를 문자로 바꾸는 함수
function stringifyNumber(value: number) {
  return String(value);
}
 
// --- 시나리오 1: 의도된 오류가 존재하는 경우 ---
// stringifyNumber는 number를 받지만, string을 전달해야 하는 특별한 이유가 있다고 가정합니다.
// @ts-expect-error 주석이 아래의 타입 에러를 정상적으로 무시합니다.
// @ts-expect-error: 레거시 API 호환성을 위해 일시적으로 허용
const result1 = stringifyNumber("123");
 
 
// --- 시나리오 2: 나중에 코드가 수정되어 오류가 사라진 경우 ---
// 만약 stringifyNumber 함수가 string 타입도 받도록 개선되었다면?
function stringifyNumberV2(value: number | string) {
  return String(value);
}
 
// 에러 발생: Unused @ts-expect-error directive.
// 기존 코드의 타입 에러가 사라졌으므로, @ts-expect-error 주석이 이제는
// 불필요하다는 새로운 에러가 발생합니다. 개발자는 이 주석을 안전하게 제거할 수 있습니다.
// @ts-expect-error: 레거시 API 호환성을 위해 일시적으로 허용
const result2 = stringifyNumberV2("123");

import { z } from 'zod';
 
// 1. Zod 스키마로 데이터의 '규칙'을 정의.
//    (e.g., price는 양수여야 한다는 비즈니스 로직까지 포함 가능)
const ProductSchema = z.object({
  id: z.number(),
  name: z.string().min(1), // 이름은 최소 1글자 이상
  price: z.number().positive(), // 가격은 0보다 커야 함
});
 
// 2. 스키마로부터 TypeScript 타입을 자동으로 '추론'한다. (z.infer)
//    이제 'interface Product'를 수동으로 만들 필요가 없다!
type Product = z.infer<typeof ProductSchema>;
 
// 3. 제네릭을 활용해 공통 API 응답 스키마도 만들 수 있다.
const ApiResponseSchema = <T extends z.ZodTypeAny>(dataSchema: T) =>
  z.object({
    success: z.boolean(),
    data: dataSchema,
  });
 
// 4. 함수에서 데이터 검증 및 사용
function handleProductResponse(response: unknown) {
  // Product 데이터가 담긴 API 응답을 검증하기 위한 최종 스키마
  const ProductResponseSchema = ApiResponseSchema(ProductSchema);
 
  // 런타임에 데이터를 파싱하고 검증합니다.
  // 실패하면 에러를 던지고, 성공하면 완벽히 타입이 보장된 객체를 반환한다.
  const validated = ProductResponseSchema.parse(response);
 
  // 'validated.data'는 이제 'Product' 타입임이 100% 보장된다.
  // 자동완성도 완벽하게 동작한다.
  console.log(validated.data.name);
  console.log(validated.data.price);
}