예제 1: 가상의 사용자 정보 API

API 엔드포인트: https://api.example.com/users

응답 예시:

{
  "id": 1,
  "name": "John Doe",
  "email": "john.doe@example.com",
  "address": {
    "street": "123 Main St",
    "city": "Anytown",
    "zipcode": "12345"
  },
  "phone": "123-456-7890",
  "website": "https://example.com"
}

1. string으로 일단 만들기

// Address 타입 정의
interface Address {
  street: string;
  city: string;
  zipcode: string;
}

// User 타입 정의
interface User {
  id: number;
  name: string;
  email: string;
  address: Address;
  phone: string;
  website: string;
}

API 호출 함수

fetch를 사용하여 데이터를 호출하고 타입을 적용합니다.

async function fetchUsers(): Promise<User[]> {
  const response = await fetch("https://api.example.com/users");
  if (!response.ok) {
    throw new Error("Failed to fetch users");
  }
  return await response.json();
}

2. string을 지양하기

: 이메일과 웹사이트URL 전화번호 타입 구체화 하기

// 이메일 타입 정의
type EmailAddress = `${string}@${string}.${string}`;

// 웹사이트 URL 타입 정의
type WebsiteURL = `http${"s" | ""}://${string}.${string}`;

// 전화번호 타입 정의
type PhoneNumber = `${number}-${number}-${number}`;

// Address 타입 정의
interface Address {
  street: string;
  city: string;
  zipcode: `${number}`; // 우편번호를 숫자로 제한
}

// User 타입 정의
interface User {
  id: number;
  name: string;
  email: EmailAddress; // 엄격한 이메일 형식
  address: Address;
  phone: PhoneNumber; // 간단한 전화번호 형식
  website: WebsiteURL; // 웹사이트 URL 형식
}

올바른 값

const user: User = {
  id: 1,
  name: "John Doe",
  email: "john.doe@example.com",
  address: {
    street: "123 Main St",
    city: "Anytown",
    zipcode: "12345"
  },
  phone: "123-456-7890",
  website: "https://example.com"
};

잘못된 값 (컴파일 오류 발생)

const invalidUser: User = {
  id: 2,
  name: "Jane Doe",
  email: "jane.doe[at]example.com", // 오류: 이메일 형식이 아님
  address: {
    street: "456 Elm St",
    city: "Othertown",
    zipcode: "abcde" // 오류: 숫자 형식이 아님
  },
  phone: "1234567890", // 오류: 전화번호 형식이 아님
  website: "example.com" // 오류: URL 형식이 아님
};

4. 브랜딩하기

: 있으면 하자 !

그렇다면 any와 unknown은 명세서와 타입 설계시 언제 사용하나요 ?

any, unknown 특징

언제 unknown을 사용할까?

: unknown은 타입 안전성을 유지해야 하지만 데이터의 구체적인 타입을 사전에 알 수 없는 경우에 적합합니다.

1. 외부에서 오는 데이터 (API 응답 구조가 문서화되지 않았거나 동적으로 변할 가능성이 있을 때.)

async function fetchData(url: string): Promise<unknown> {
  const response = await fetch(url);
  return response.json();
}

async function processData() {
  const data: **unknown**= await fetchData("https://api.example.com/data");

  // 타입 좁히기 필요
  if (Array.isArray(data)) {
    console.log(`Array of length: ${data.length}`);
  } else if (typeof data === "object" && data !== null) {
    console.log(`Object with keys: ${Object.keys(data)}`);
  } else {
    console.log("Unknown data type");
  }
}

• 장점: 타입을 검사하기 전까지는 데이터를 조작할 수 없으므로, 실수를 방지할 수 있습니다.
• 단점: 추가적인 타입 검사 코드가 필요합니다.

2. 안전하게 다뤄야 할 데이터가 있을 때

unknown은 강제로 타입을 좁혀야 하기 때문에 더 안전하게 데이터를 사용할 수 있습니다.

function processValue(value: unknown) {
  if (typeof value === "string") {
    console.log(value.toUpperCase()); // 안전
  } else if (typeof value === "number") {
    console.log(value.toFixed(2)); // 안전
  } else {
    console.log("Unsupported type");
  }
}

언제 any를 사용할까?

: any는 타입 안전성을 무시하고 빠르게 코드를 작성해야 할 때 사용합니다. 하지만 남용을 피해야 하며, 가능한 빨리 정확한 타입으로 대체하는 것이 좋습니다.

1. 빠른 프로토타이핑

개발 초기 단계에서 타입 정의가 아직 명확하지 않거나, 많은 데이터를 테스트해야 할 때 유용합니다.

function logData(data: any) {
  console.log(data);
}

logData({ id: 1, name: "John Doe" });
logData("This is a string");
logData(42);

• 장점: 유연성.
• 단점: 모든 작업이 허용되므로, 타입 오류를 놓칠 가능성이 큽니다.

2. 타입 검사가 필요 없는 경우

특정 로직이 타입에 구애받지 않고 모든 데이터 타입을 다뤄야 할 때 사용합니다.

function mergeObjects(obj1: any, obj2: any): any {
  return { ...obj1, ...obj2 };
}

• 예: 데이터 직렬화/역직렬화, JSON.parse(), 로깅.

unknown vs any 사용 사례 비교

const jsonData: **any** = JSON.parse('{"id": 1, "name": "John"}');
console.log(jsonData.toUpperCase()); // 런타임 오류 발생 가능 (TypeScript가 경고하지 않음)

const unknownData: **unknown** = JSON.parse('{"id": 1, "name": "John"}');
if (typeof unknownData === "string") {
  console.log(unknownData.toUpperCase()); // 비교적 안전
} else {
  console.log("Data is not a string");
}

• any: 런타임 오류 가능성이 있음.
• unknown: 타입 검사 후 사용 가능, 타입 안전성 증가.

예제 2: 상표가 있는 API

{
  "id": "12345",
  "name": "Apple MacBook Pro",
  "category": "laptop",
  "price": 2499.99,
  "currency": "USD",
  "availability": {
    "inStock": true,
    "estimatedDeliveryDays": 5
  },
  "rating": {
    "average": 4.8,
    "reviews": 1245
  }
}

1. API 명세 읽고 타입 설계 (string 중심)

우선, API 데이터 구조를 단순히 string 및 기타 기본 타입으로 표현합니다.

interface Product {
  id: string; // 제품 ID
  name: string; // 제품 이름
  category: string; // 제품 카테고리
  price: number; // 제품 가격
  currency: string; // 통화 단위
  availability: {
    inStock: boolean; // 재고 여부
    estimatedDeliveryDays: number; // 예상 배송일
  };
  rating: {
    average: number; // 평균 평점
    reviews: number; // 리뷰 수
  };
}

2. string으로 표현된 타입 이름을 해당 분야로 지정

타입 이름을 구체화하여 해당 데이터와 연관된 도메인 용어를 반영합니다.

type ProductID = string;
type ProductName = string;
type ProductCategory = string;
type Currency = string;

interface Product {
  id: ProductID;
  name: ProductName;
  category: ProductCategory;
  price: number;
  currency: Currency;
  availability: {
    inStock: boolean;
    estimatedDeliveryDays: number;
  };
  rating: {
    average: number;
    reviews: number;
  };
}

이 단계에서는 단순히 의미를 부여한 별칭을 도입했습니다. 타입 자체는 여전히 string 기반입니다.

3. string 지양하고 구체적인 타입으로 좁히기

이제 더 구체적인 타입으로 좁힙니다. 예를 들어:

• Currency는 ISO 4217 표준 코드로 한정합니다.
• ProductCategory는 정해진 카테고리 값으로 제한합니다.

type ProductID = `${number}`; // ID는 숫자 기반 문자열
type ProductName = string;

type ProductCategory = "laptop" | "smartphone" | "tablet" | "accessory"; // 카테고리 제한

type Currency = "USD" | "EUR" | "JPY"; // ISO 4217 통화 코드

interface Product {
  id: ProductID;
  name: ProductName;
  category: ProductCategory;
  price: number;
  currency: Currency;
  availability: {
    inStock: boolean;
    estimatedDeliveryDays: number;
  };
  rating: {
    average: number;
    reviews: number;
  };
}

이 단계에서는 string 대신 구체적인 값으로 제한하여 데이터 구조의 타입 안전성을 향상시켰습니다.

4. 공식 명칭에 상표(branding) 붙이기

마지막으로, 상표를 추가하여 타입의 고유성을 강화합니다. 상표를 추가하면 다른 동일 구조의 타입과 구별할 수 있습니다.

type ProductID = `${number}` & { _brand: "ProductID" };
type ProductName = string & { _brand: "ProductName" };

type ProductCategory = "laptop" | "smartphone" | "tablet" | "accessory" & { _brand: "ProductCategory" };

type Currency = "USD" | "EUR" | "JPY" & { _brand: "Currency" };

interface Product {
  id: ProductID;
  name: ProductName;
  category: ProductCategory;
  price: number;
  currency: Currency;
  availability: {
    inStock: boolean;
    estimatedDeliveryDays: number;
  };
  rating: {
    average: number;
    reviews: number;
  };
}

• 이제 ProductID나 Currency는 동일한 구조의 다른 string과 구별됩니다.
• 타입 간 혼동을 방지하고, 잘못된 데이터 사용 가능성을 줄입니다.

const macbook: Product = {
  id: "12345" as ProductID,
  name: "Apple MacBook Pro" as ProductName,
  category: "laptop" as ProductCategory,
  price: 2499.99,
  currency: "USD" as Currency,
  availability: {
    inStock: true,
    estimatedDeliveryDays: 5,
  },
  rating: {
    average: 4.8,
    reviews: 1245,
  },
};

퀴즈 ‼️

아래의 Product 타입은 특정 API 명세를 기반으로 설계되었습니다. 다음 중 올바르지 않은 부분은 무엇일까요

type ProductID = `${number}` & { _brand: "ProductID" };
type ProductCategory = "laptop" | "smartphone" | "tablet" | "accessory" & { _brand: "ProductCategory" };
type Currency = "USD" | "EUR" | "JPY" & { _brand: "Currency" };

interface Product {
  id: ProductID;
  name: string;
  category: ProductCategory;
  price: number;
  currency: Currency;
  availability: {
    inStock: boolean;
    estimatedDeliveryDays: number;
  };
}

const productB: Product = {
  id: "102" as ProductID,
  name: "Apple iPad",
  category: "tablet" as ProductCategory,
  price: 599.99,
  currency: "GBP" as Currency,
  availability: {
    inStock: false,
    estimatedDeliveryDays: 7,
  },
};

• 답

  currency가 GBP로 설정되어 있습니다. Currency 타입은 "USD", "EUR", "JPY"만 허용합니다.

1. 원시 타입과 참조형 타입의 차이점

• 원시 타입 (Primitive Types): JavaScript의 숫자, 문자열, 불리언, null, undefined와 같은 타입을 포함합니다. 원시 타입은 값 자체를 저장하고, 변수에 값을 할당해도 다른 변수에는 영향을 주지 않습니다.

  • 예시:

      let a = 10;
      let b = a;
      b = 20;
      console.log(a); // 10
      console.log(b); // 20

    • a와 b는 독립적인 값으로, 하나를 변경해도 다른 변수에는 영향을 미치지 않습니다.

• 참조형 타입 (Reference Types): 객체, 배열, 함수 등으로, 변수에는 참조(메모리 주소)가 저장됩니다. 참조형 타입은 주소를 저장하고 있기 때문에, 하나의 객체를 여러 변수에 할당하면, 하나를 변경할 경우 나머지 변수들도 영향을 받습니다.

  • 예시:

      let obj1 = { name: 'Alice' };
      let obj2 = obj1;
      obj2.name = 'Bob';
      console.log(obj1.name); // 'Bob'
      console.log(obj2.name); // 'Bo

    • obj1과 obj2는 같은 객체를 참조하고 있기 때문에, 하나를 수정하면 다른 것도 변경됩니다.

2. 얕은 복사 (Shallow Copy)

얕은 복사는 객체의 1단계만 복사하고, 중첩된 객체는 여전히 원본 객체와 동일한 참조를 공유합니다. 이 말은 중첩된 객체나 배열에 변경이 일어나면 원본 객체에 영향을 미친다는 뜻입니다.

• 예시:

    const clubInfo = {
      name: 'COW Club',
      members: [
        { name: 'John', fee: 100, part: 'Server', isAttending: true },
        { name: 'Sara', fee: 150, part: 'Web', isAttending: false }
      ]
    };
  
    const newClubInfo = { ...clubInfo }; // 얕은 복사
  
    // 중첩된 객체는 여전히 참조를 공유
    newClubInfo.members[0].fee = 200;
  
    console.log(clubInfo.members[0].fee); // 200
    console.log(newClubInfo.members[0].fee); // 200

  • 위 코드에서 newClubInfo는 clubInfo의 얕은 복사본을 만들었지만, members 배열 안의 객체는 여전히 같은 메모리 주소를 참조하고 있습니다. 따라서 newClubInfo.members[0]을 수정하면 clubInfo.members[0]에도 영향을 미칩니다.

3. 깊은 복사 (Deep Copy)

깊은 복사는 객체의 모든 중첩된 속성까지 독립적으로 복사하는 방식입니다. 깊은 복사를 사용하면 원본 객체와 복사본 객체가 서로 영향을 미치지 않습니다.

• 예시:

    const clubInfo = {
      name: 'COW Club',
      members: [
        { name: 'John', fee: 100, part: 'Server', isAttending: true },
        { name: 'Sara', fee: 150, part: 'Web', isAttending: false }
      ]
    };
  
    const deepCopyClubInfo = JSON.parse(JSON.stringify(clubInfo)); // 깊은 복사
  
    // 깊은 복사본에서 변경
    deepCopyClubInfo.members[0].fee = 200;
  
    console.log(clubInfo.members[0].fee); // 100
    console.log(deepCopyClubInfo.members[0].fee); // 200

  • JSON.parse(JSON.stringify()) 방법은 객체의 깊은 복사를 수행합니다. 이 방식은 객체 내부의 모든 속성을 복사하고, 원본 객체와 복사본이 완전히 독립적인 객체로 존재합니다.

4. 얕은 복사 vs 깊은 복사: 어떤 경우에 사용해야 할까?

• 얕은 복사는 배열이나 객체의 1단계 속성만 복사할 때 유용합니다. 중첩된 데이터가 없거나, 중첩된 데이터를 수정할 필요가 없는 경우 적합합니다.
• 깊은 복사는 객체나 배열이 중첩된 구조를 가지고 있고, 중첩된 데이터까지 독립적으로 다뤄야 할 때 사용합니다.

5. React에서 불변성(Immutability)과 상태 관리

React에서는 상태를 직접 수정하지 않고, 새로운 객체를 생성하여 상태를 업데이트해야 합니다. 이 과정에서 불변성(Immutability)을 지키는 것이 매우 중요합니다. 불변성을 지키면 React가 상태 변화(예: setState)를 쉽게 추적하고, 효율적인 리렌더링을 할 수 있습니다.

• 불변성을 유지하는 이유:

  • React는 참조 비교를 통해 상태 변경을 감지합니다. 상태를 변경할 때마다 새로운 객체를 생성하면, React는 이전 상태와 새로운 상태를 비교하여 리렌더링을 최적화할 수 있습니다.
  • 불변성을 유지하면 코드가 더 예측 가능하고, 상태 관리가 쉬워집니다.

• 불변성 예시:

    const [members, setMembers] = useState([
      { name: 'John', fee: 100, part: 'Server', isAttending: true },
      { name: 'Sara', fee: 150, part: 'Web', isAttending: false }
    ]);
  
    // 불변성을 유지하면서 상태 업데이트
    const updateFee = (index, newFee) => {
      const updatedMembers = [...members]; // 얕은 복사
      updatedMembers[index] = { ...updatedMembers[index], fee: newFee }; // 중첩 객체 복사
      setMembers(updatedMembers); // 새로운 배열로 상태 업데이트
    };

퀴즈

1. 얕은 복사와 깊은 복사에 대한 설명이 올바른 것은?
   1. 얕은 복사는 중첩된 객체까지 독립적으로 복사하고, 깊은 복사는 객체의 1단계만 복사한다.
   2. 얕은 복사는 객체의 1단계만 복사하고, 깊은 복사는 중첩된 객체까지 독립적으로 복사한다.
   3. 얕은 복사는 객체와 배열을 모두 복사하고, 깊은 복사는 객체만 복사한다.
   4. 얕은 복사는 값 타입만 복사하고, 깊은 복사는 참조 타입만 복사한다.
2. 다음 중 깊은 복사를 수행하는 방법으로 올바른 것은?
   1. Object.assign()
   2. JSON.parse(JSON.stringify())
   3. ... (스프레드 연산자)
   4. slice()
3. 불변성을 지키지 않았을 때 발생할 수 있는 문제는 무엇인가요?
   1. React의 리렌더링 최적화가 이루어지지 않거나 예기치 않은 동작이 발생할 수 있다.
   2. 상태 업데이트가 불가능해진다.
   3. 코드가 더 간결해진다.
   4. 상태를 직접 변경할 수 없게 된다.
4. React에서 상태를 업데이트할 때 얕은 복사를 사용하는 이유는 무엇인가요?
   1. 값 타입만 복사하고, 객체 타입을 무시하기 위해서
   2. 중첩된 객체가 변경되지 않기 때문에
   3. 상태를 변경할 때 새로운 객체를 생성하여 불변성을 지키기 위해서
   4. React에서 상태를 직접 변경할 수 없기 때문에
5. 스프레드 연산자를 사용한 얕은 복사의 예시로 올바른 코드는?
   1. const newObj = { ...obj };
   2. const newObj = obj;
   3. const newObj = Object.assign({}, obj);
   4. const newObj = JSON.parse(JSON.stringify(obj));

컴포넌트에는

ToDo 내용을 삭제하고 관리하는 부분은 같이 하고 있어요 그래서 그 부분을 useContext와 데이터를 수정하는 부분은 useReducer을 통해서 구현해봤습니다.

TodoContext.tsx

import { createContext, useReducer } from "react";

const initialState = {
  todos: [
    { title: "첫번째 투두", id: 1, isCompleted: false, isEditing: false },
  ],
};

const todoReducer = (state: typeof initialState, action: any) => {
  switch (action.type) {
    case "ADD_TODO":
      return { todos: [...state.todos, action.payload] };
    case "REMOVE_TODO":
      return {
        todos: state.todos.filter((todo) => todo.id !== action.payload.id),
      };
    default:
      return state;
  }
};

export const TodoStateContext = createContext<typeof initialState | null>(null);
export const TodoDispatchContext = createContext<any>(null);

export const TodoProvider = ({ children }: { children: React.ReactNode }) => {
  const [state, dispatch] = useReducer(todoReducer, initialState);

  return (
    <TodoStateContext.Provider value={state}>
      <TodoDispatchContext.Provider value={dispatch}>
        {children}
      </TodoDispatchContext.Provider>
    </TodoStateContext.Provider>
  );
};

여기서 생긴 문제는

한국어만 생성시 마지막 글자가 하나 더 추가된다는 것이였습니다 밥먹기, 기 처럼.. . .

keydown에서 keyup으로 변경해주었씁니다 !

import { useEffect } from "react";

function useEnterKey(callback: () => void) {
  useEffect(() => {
    const handleKeyUp = (event: KeyboardEvent) => {
      if (event.key === "Enter") {
        event.preventDefault();
        callback();
      }
    };

    window.addEventListener("keyup", handleKeyUp);

    return () => {
      window.removeEventListener("keyup", handleKeyUp);
    };
  }, [callback]);

  return;
}

export default useEnterKey;

해당 방법으로 적용했더니 해결되었습니다 keyup 이벤트를 사용하여 해결되었습니다. keydown이 아닌 keyup을 사용하면 사용자가 키를 떼었을 때 동작하므로 중복 입력이 발생하지 않게 되므로 해당 방법으로 해결할 수 있었습니다

다른 컴포넌트 마저 완성하고 구현을 완료하였습니다.

todoItem에 있는 delete, toggle addTodo에 있는 all toggle filter에 있는 Clear complete 부분은 useReducer과 연결하여 같이 데이터를 다룰 수 있도록 처리하였습니다.

filter에 있는 아이템 갯수와 mode는 state로 처리하였습니다

지난번에 이런식으로 컴포넌트를 분리하기로 하였씁니다

ui에서는 크게 컴포넌트를

1. AddTodo.tsx
2. TodoFilter.tsx,
3. TodoItem.tsx 3개로 나누었습니다. (1편 참고)

현재는 todoList를 context로 (todoContext) 관리하고 todoList의 데이터 수정은 Reducer로 (todoReducer) 시각적인 todoList의 필터는 state로 관리하고있습니다 ( mode )

그래서 전역관리는

todoContext.tsx

import { createContext, useReducer } from "react";
import { todoList } from "../types/todo";

const initialState: todoList = {
  todos: [],
};

type Action =
  | { type: "ADD_TODO"; payload: { title: string } }
  | { type: "REMOVE_TODO"; payload: { id: number } }
  | { type: "TOGGLE_TODO"; payload: { id: number } }
  | { type: "CLEAR_COMPLETED_TODOS"; payload: null }
  | { type: "ALL_TOGGLE_TODO" };

const todoReducer = (state: todoList, action: Action): todoList => {
  switch (action.type) {
    case "ADD_TODO":
      return {
        todos: [
          ...state.todos,
          {
            ...action.payload,
            id: Date.now(),
            isCompleted: false,
            isEditing: false,
          },
        ],
      };
    case "REMOVE_TODO":
      return {
        todos: state.todos.filter((todo) => todo.id !== action.payload.id),
      };
    case "TOGGLE_TODO":
      return {
        todos: state.todos.map((todo) =>
          todo.id === action.payload.id
            ? { ...todo, isCompleted: !todo.isCompleted }
            : todo
        ),
      };
    case "CLEAR_COMPLETED_TODOS":
      return { todos: state.todos.filter((todo) => !todo.isCompleted) };
    case "ALL_TOGGLE_TODO":
      return {
        todos: state.todos.map((todo) =>
          todo.isCompleted
            ? { ...todo, isCompleted: false }
            : { ...todo, isCompleted: true }
        ),
      };
    default:
      return state;
  }
};

export const TodoStateContext = createContext<todoList | null>(null);
export const TodoDispatchContext = createContext<React.Dispatch<Action> | null>(
  null
);

export const TodoProvider = ({ children }: { children: React.ReactNode }) => {
  const [state, dispatch] = useReducer(todoReducer, initialState);

  return (
    <TodoStateContext.Provider value={state}>
      <TodoDispatchContext.Provider value={dispatch}>
        {children}
      </TodoDispatchContext.Provider>
    </TodoStateContext.Provider>
  );
};

다음과 같이 작성하였습니다. Reducer과 Context를 같이 관리하고 있습니다. 이는 역할이 다르기에 다음주차때 분리할 것을 보입니다.

현재 제가 짠 코드에 대해서 설명을 덧붙히자면 전체 컴포넌트에서 todoList를 다루고있지는 앉지만 전체 컴포넌트에서 데이터 수정을 진행하고 있다는 점에서 todoReducer로 데이터 관리를 전역적으로 관리하는 것으로 구현하였습니다 그리고 mode같은 경우에는 현재 state로 받고있습니다

App.tsx

import { useState } from "react";
import { useContext } from "react";
import { TodoStateContext, TodoDispatchContext } from "./context/TodoContext";
import TodoItem from "./components/TodoItem";
import AddTodo from "./components/AddTodo";
import TodoFilter from "./components/TodoFilter";
import { todo, todoFilter } from "./types/todo";

function App() {
  const { todos } = useContext(TodoStateContext) ?? { todos: [] };
  const dispatch = useContext(TodoDispatchContext);
  const [mode, setMode] = useState<todoFilter>("All");

  return (
    <div className="flex flex-col items-center justify-center h-screen bg-gray-100">
      <h1 className="text-4xl py-2">Todo List</h1>
      <div>
        <div className="overflow-y-scroll max-h-96 bg-gray-200 rounded-lg rounded-b-none shadow-lg">
          <AddTodo dispatch={dispatch} />
          {todos?.map((todo: todo) => (
            <TodoItem
              key={todo.id}
              content={todo.title}
              isChecked={todo.isCompleted}
              id={todo.id}
              mode={mode}
            />
          ))}
        </div>
        <TodoFilter setMode={setMode} mode={mode} todoLength={todos.length} />
      </div>
    </div>
  );
}

export default App;

mode를 state로 구현한 이유?

todoFilter 에서 선택한 mode를 todoItem에 단순히 뿌려주는 구성이지만 반면 데이터 수정같은 경우에는 서로 상호작용을 하기 때문에 mode는 state로 구현하였습니다

내가 생각하는 앞으로 개선해야될 점

1. 현재 상태 관리 방법인 useContext와 useReducer를 사용하고 있지만, 이 방식이 정말 최적인지 고민할 필요가 있습니다. 특히 애플리케이션이 커지거나 복잡해질 때 이 방식이 확장성이나 성능에 문제가 생길 수 있기 때문입니다. 그래서 다른 상태 관리 라이브러리를 써보며 비교하고 성능을 측정하고 싶습니다.

2. 컴포넌트나 함수가 하나의 책임만 가지도록 해야 유지보수나 확장이 용이합니다. 예를 들어, TodoItem 컴포넌트는 단지 아이템을 표시하고 수정하는 역할만 해야 합니다. 상태 관리 로직과 UI 로직을 분리하여, 코드의 책임을 명확히 할 수 있습니다. 현재는 아이콘과 삭제하는 역할도 같이 하고 있기에 이 부분을 개선하는 방안을 고려해보고자 합니다.

3. 컴포넌트가 너무 많으면 관리가 어려워질 수 있고, 너무 적으면 코드가 복잡해집니다. 상태 관리와 UI를 적절히 분리하고, 재사용 가능한 컴포넌트를 만들어야 합니다. 2번 과정을 거치다가 너무 많은 컴포넌트를 남발할 수 있기에 이를 주의하며 최적의 코드를 짜고자합니다

3주차때 뵙겠습니다 ~~

동아리에서 "우아한 리액트 타입스크립트" 책을 읽으며  TodoMVC 프로젝트를 진행하기로하였습니다 ! 

프로젝트를 시작하기 전, 이 프로젝트를 통해 어떤 걸 얻고 싶은지 먼저 정리해봤습니다.
크게 네 가지 목표 정했는데

1. 리액트 훅을 효율적으로 활용하기
   • 이전에는 훅을 단순히 "이럴 때 쓰는 거구나" 정도로만 이해하고 무조건 사용했던 경향이 있었습니다.
   • 이번에는 "왜 이 훅을 써야 하는지", "지금 이 구조에서 최선인지" 등을 고민하며 제대로 활용해보고 싶습니다.
2. 작고 명확한 컴포넌트 설계
   • 예전에는 컴포넌트를 크고 뭉뚱그려 짰고, “어차피 나 혼자 볼 거니까” 라는 생각도 있었습니다.
   • 하지만 이제는 하나의 책임만 가지는 컴포넌트 단위로 분리해, 재사용성과 유지보수성을 고려한 구조를 만들고자 합니다.
3. 명확한 함수/변수 네이밍과 가독성 있는 코드 작성
   • 함수명이 모호하거나 중복된 역할을 하는 경우가 많았습니다. 예를 들어, handlePrintSomething처럼 명확하지 않은 경우요.
   • 이번엔 기능을 정확히 설명하는 네이밍, 그리고 꼭 필요한 주석만을 추가해 직관적인 코드 를 지향합니다.
4. 상태 관리 최적화: useReducer + Context 적용
   • props drilling으로 인한 렌더링 이슈를 줄이고, 상태를 더 깔끔하게 관리하기 위해 useReducer와 Context API를 적극 활용해보려 합니다.

추가적으로 프로젝트가 어느 정도 안정화되면
Jest와 React Testing Library를 도입해 테스트 코드를 작성하고,
변경에 강한 구조를 만들어보고 싶습니다.

1. 프로젝트 구성 선택: 왜 Vite + Tailwind인가?

요즘 많이 쓰이는 Next.js / Vite / Vanilla 중 고민이 있었지만, 최종적으로는 Vite + Tailwind 조합으로 결정했습니다.

• 왜 Vite?
  SSR보다는 컴포넌트 구조와 훅 사용에 초점을 두고 있어, 빠르고 가벼운 환경의 Vite를 선택했습니다.
• 왜 Tailwind?
  스타일링보다는 기능과 구조 설계에 집중하고 싶었기 때문에, 빠르게 UI를 구성할 수 있는 Tailwind를 도입했습니다

초기 설정 작업

• 프로젝트 생성: npm create vite@latest
• Tailwind 설치 및 설정: npm install -D tailwindcss postcss autoprefixer

2. 코드 스타일 및 품질 도구 설정

Eslint + Prettier 설정

혼자 하는 프로젝트라고 해도 코드 가독성은 결국 미래의 나를 위한 투자라고 생각합니다.
나중에 다시 보았을 때 "이게 뭐였지?" 싶은 코드를 줄이기 위해,
초반부터 코딩 스타일을 통일하고 일관된 룰을 적용하기 위해 ESLint와 Prettier를 설정했습니다.

• 코드가 자동으로 정돈되어 시간도 절약되고
• 협업 시 스타일 충돌 없이 코드 리뷰에 집중할 수 있는 기반도 다질 수 있다고 생각합니다.

Husky 설정

혼자 하는 프로젝트라도 무심코 규칙을 어기면 프로젝트가 내부적으로 무너질 수 있다고 생각합니다.
그래서 Git hook을 통해 규칙을 강제하기 위해 husky를 설정했습니다.

3. 컴포넌트 설계 및 구조화

예전에는 ‘일단 기능부터 만들자’는 생각으로 코드를 짜왔지만,
이번 프로젝트에서는 개발에 들어가기 전에 컴포넌트의 역할을 먼저 설계하고 구조를 정리해보았습니다.

고민했던 포인트는 다음과 같아요:

• 어떻게 하면 각 컴포넌트가 하나의 책임만 가지도록 나눌 수 있을까?
• 추후에 재사용하거나 유지보수할 때 코드의 의도가 쉽게 드러날까?
• props 전달이 너무 깊어지지 않게 설계할 수 있을까?

예상되는 컴포넌트 목록:

1. Button.tsx: 기본 버튼 UI 컴포넌트
2. Icon.tsx: 아이콘 처리 컴포넌트
3. TodoInput.tsx: 할 일 추가 입력창
4. TodoList.tsx: 투두 목록 전체를 보여주는 컴포넌트
5. TodoItem.tsx: 각각의 투두 항목
6. TodoFilter.tsx: 전체/완료/미완료 필터링 기능

필요한 훅 구성

1. useTodoController:
   • 투두 추가/삭제/수정 같은 핵심 로직을 담는 훅
   • 상태 조작은 이 훅에서만 일어나게 분리하는 것이 목표입니다.
2. useTodoFilter:
   • 필터에 따라 보여줄 투두를 처리하는 훅
   • 렌더링을 최소화하고, 조건별 필터링을 깔끔하게 분리하고 싶어요.
3. useEnterClick:
   • 키보드에서 Enter를 눌렀을 때 동작을 감지하는 재사용 가능한 유틸성 훅

이렇게 미리 컴포넌트와 훅을 나눠 생각해두면,
구현을 시작할 때 불필요한 혼란을 줄일 수 있고 코드의 방향성도 명확해진다고 느꼈습니다.

4. 폴더 구조 설계

처음에는 FSD 패턴 도입을 고민했지만, 현재 다른 프로젝트에서 적용 중이므로 이번 프로젝트에서는 간단한 기능 중심 구조를 선택했습니다.

├── components
│   └── ... (UI 컴포넌트)
├── hooks
│   └── useTodoController.ts
├── contents
│   └── ... (상수, config 등)
├── assets
│   └── ... (아이콘, 이미지)
├── App.tsx
├── main.tsx

마무리

Todo라는 작은 프로젝트이지만, 유지보수성과 설계 원칙을 잘 적용한다면 큰 프로젝트에서도 많은 도움이 될 것이라 믿고, 약간은 과할 수도 있는 목표를 가지고 출발.........

최대한 얻어갈 수 있도록 블로그에 하나하나 남겨보겠습니다 !!

기존에 Select 컴포넌트 코드는 이러합니다.

'use client';
import React, { useState } from 'react';
import { Icon } from '../Icon';

type Props = {
  contents: string[];
  size?: 'md' | 'lg';
  placeholder?: string;
};

export function Select({ contents, size, placeholder }: Props) {
  const [selectedContent, setSelectedContent] = useState(placeholder ? placeholder : contents[0]);
  const [openSelect, setOpenSelect] = useState(false);

  return (
    <div
      className={`${openSelect ? 'rounded-lg' : 'rounded-lg border border-gray-100'} text-b'${
        size === 'md' ? 'md:min-w-26 w-fit min-w-24' : 'md:min-w-66 w-60'
      } cursor-pointer border border-gray-200 bg-white text-start text-base font-semibold text-gray-400 md:text-lg`}
    >
      <div
        className={`${
          openSelect
            ? 'border-b-2 border-gray-100 hover:rounded-lg hover:rounded-b-none'
            : 'border-0'
        } flex justify-between ${
          size === 'md' ? 'items-center py-1 pl-3 pr-2 text-sm' : 'px-5 py-2 md:py-3'
        } hover:rounded-md hover:bg-gray-50`}
        onClick={() => setOpenSelect(!openSelect)}
      >
        {selectedContent}

        <Icon
          name="arrowDown"
          className={`transform transition-transform duration-300 ${
            openSelect ? 'rotate-180' : ''
          } ${size === 'md' ? 'w-5' : ''} }`}
        />
      </div>

      {openSelect && (
        <div className="flex flex-col">
          {contents.map((item, key) => (
            <div
              onClick={() => {
                setSelectedContent(contents[key]);
                setOpenSelect(!openSelect);
              }}
              className={`cursor-pointer border-gray-100 ${
                size === 'md' ? 'px-3 py-1 text-sm' : 'px-5 py-2 md:py-3'
              } last:border-none hover:bg-gray-50 hover:last:rounded-b-md`}
              key={key}
            >
              {item}
            </div>
          ))}
        </div>
      )}
    </div>
  );
}

무언가 한덩이로 크게 묶여져있는 Select 코드..

모든 로직과 스타일이 하나의 컴포넌트 안에 꽉 묶여 있었습니다. 선택된 항목 상태 관리부터 드롭다운 토글, 아이템 렌더링, 스타일링까지… 모든 역할이 한 파일에 들어있는 모습입니다.

Select 뿐만 아니라 GroupingComponent도 있는데 groupName만 추가된 형태임에도 새로운 컴포넌트를 만들어야됐습니다

이 경험을 계기로 자연스럽게 이런 질문을 던지게 됐습니다.

Q1. Select 컴포넌트의 ‘책임’은 어디까지여야 할까? Q2. 조금 다른 UI/동작을 위해 새로운 컴포넌트를 만드는 것이 과연 효율적인가? Q3. 재사용성과 확장성을 모두 고려한 UI 컴포넌트 설계 기준은 무엇인가?

이 고민은 단순한 리팩토링을 넘어, "컴포넌트는 기능 단위가 아니라 역할 단위로 쪼개야 한다"는 깨달음으로 이어졌습니다.

리팩토링 방향을 얻은 인사이트

Effective Component 강의 「지속 가능한 성장과 컴포넌트」를 보고 다음과 같은 인사이트를 얻었습니다.

컴포넌트를 나누는 기준

1. Headless 기반으로 추상화하기

변하는 것과 변하지 않는 것을 나누자.
데이터는 같지만 UI는 달라질 수 있다면 UI와 데이터를 분리하자.

• 예: 달력
  • 데이터는 훅으로 관리 (예: useCalendar)
  • UI는 별도 분리 → Headless 모듈화

💡 변화하는 부분은 훅, 보여지는 부분은 컴포넌트로 분리

2. 한 가지 역할만 하기 → Composition Pattern

하나의 역할을 가진 컴포넌트를 여러 개 조합해서 구성하자.

• 예: Select
  • 선택된 값을 보여주는 Trigger
  • 드롭다운 메뉴인 Menu
  • 실제 아이템 목록인 Item

→ 이벤트 흐름: onClick → onChange

이렇게 하면 각 컴포넌트는 서로를 몰라도 되고, 독립적으로 재사용 가능

3. 도메인 분리하기

데이터 주입받는 방식도 컴포넌트처럼 분리해야 한다.

• 도메인을 알지 못하는 컴포넌트
• 도메인을 포함하는 컴포넌트

이 둘을 분리하면 외부 의존성 없이도 관리하기 쉬움

예: 인터페이스 정의부터 고민하기

해당 영상을 보고 Select 컴포넌트의 문제를 명확하게 알 수 있었습니다.

만약 이 Select에 MultiSelect나 검색 기능이 추가된다면, 어디부터 손대야되는지 막막했습니다. 기능을 더하려 할수록 점점 커지고, 더 복잡해지는 컴포넌트. 확장에는 약하고, 변경에는 민감한 구조라는 걸 느꼈습니다. 때문에 변경에 유연한 컴포넌트 형태로 리팩토링 해야겠다고 생각이 되었습니다.

리팩토링 구조 예시

영상에서 dropdown컴포넌트를 다음과같이 구조화한 예시를 보여주었습니다

• DropdownTrigger : 열고 닫는 역할
• Menu : 리스트의 wrapper
• Item : 실제 선택할 항목
• 이벤트 흐름은 onClick → onChange

변경된 컴포넌트는 서로의 존재를 몰라도 동작합니다. 그리고 이러한 구조는 확장성과 재사용성 유지보수성을 높입니다

영상에서는 컴포넌를 짜기 위한 2가지의 흐름을 알려줍니다

1. 인터페이스 먼저 고민하기

“이 컴포넌트의 의도는 무엇인가?”
“기능보다 표현 방식이 더 중요할 수도 있다.”

2. 컴포넌트를 분리하는 이유를 항상 생각하기

• 정말 복잡도를 낮추는가?
• 정말 재사용 가능한가?

“리팩토링은 기능을 더하는 것이 아니라, 이해를 더하는 과정이다.”

새롭게 Select 컴포넌트 리팩토링 방향을 정해보았습니다

1. 역할 단위 분리: 기능을 기준으로 파일 분리를 통해 책임을 명확히 구분
2. Context 도입: 하위 컴포넌트들이 상태를 공유하도록 하여 prop drilling 제거
3. 재사용성 향상: Option, TriggerButton 등은 다른 Select 변형에도 재활용 가능
4. Storybook 구성: 유지보수 시 시각적으로 컴포넌트를 빠르게 확인 가능

1. 폴더구조 (directory structure)

Select 컴포넌트는 역할별로 책임을 나눠 확장성과 재사용성을 고려한 구조로 설계했습니다.

• index.ts: Select 관련 컴포넌트를 통합 export하는 진입 파일
• SelectMain.tsx: Select의 루트 컴포넌트로, Context를 제공하고 전체 구조를 제어
• TriggerButton.tsx: 선택된 값을 보여주고 드롭다운을 열고 닫는 버튼 역할
• OptionList.tsx: 드롭다운 영역을 구성하며, 내부에 여러 Option을 포함하는 파일
• Option.tsx: 실제 선택 가능한 항목
• OptionGroupName.tsx: 옵션을 그룹으로 묶을 때 사용하는 제목 컴포넌트
• Select.context.tsx: 선택 상태, 열림 여부 등을 관리하는 Context를 정의
• useSelectMain.ts: Select 내부 로직을 담당하는 커스텀 훅
• Select.stories.tsx: Storybook용 시각화 테스트 파일

각 파일이 명확한 역할을 가지도록 분리함으로써,기능 추가나 유지보수가 훨씬 쉬워졌습니다.

2. 상태 관리 흐름

useSelectMain: 선택 상태 및 열림 여부 등 4가지 상태를 지역 상태로 관리합니다

selected: 현재 선택된 항목 isOpen: 드롭다운 열림 여부 setIsOpen: 드롭다운 열고 닫기 제어 handleSelect: 옵션 선택 핸들러

SelectMain: UI 뼈대를 구성하고, context로 하위 컴포넌트에 상태 전달

SelectContext.Provider: context를 통해 하위 컴포넌트로 상태 전파

useSelectContext: 하위 컴포넌트들이 context 값을 받아 사용

그림으로 표현하면 이렇습니다

*구조로 나타내면 이렇게 표현할 수 있습니다 *

[useSelectMain]         ← 지역 상태 생성
      │
      ▼
[SelectMain]            ← 상태를 context로 감싸서 하위에 전달
      │
      ▼
[SelectContext.Provider]    ← context 전파
      │
      ▼
[useSelectContext()]    ← 하위 컴포넌트가 context 값 사용
      ├── Option        → onSelect, size
      └── OptionList    → size
      └── TriggerButton    → size,onSelect, selected 

그리고 마지막으로는 만들어진 컴포넌트를 조립해서 각각의 컴포넌트처럼 사용할 수 있도록 만들었습니다

느낀점

이번 리팩토링을 통해, 그동안 컴포넌트를 나눈다 = 파일/폴더 단위로 나눈다 라고만 생각했던 저 자신을 돌아보게 되었습니다.

컴포넌트는 단순히 폴더에 따라 분리하는 것이 아니라, 그 안에서도 역할(기능 vs UI) 기반으로 더 깊이 있게 나눌 수 있고, 필요한 기능을 조립해서 사용하는 ‘블록형 사고방식’이 가능하다는 것을 새롭게 체감했습니다.

하나의 Select 컴포넌트 안에서도

• 상태 관리 (useSelectMain)
• 전역 상태 공유 (SelectContext)
• UI 단위 분리 (Trigger, Option, OptionList, Group) 로 나눌 수 있다는 점에서 역할 중심의 설계 사고방식이 생겼습니다.

단순히 쓰기 좋게 만드는 게 아니라, 나중에 내가 다시 볼 때도 유용한 구조로 만드는 것이 진짜 설계라는 걸 느꼈습니다.

*잘 만든 컴포넌트는 나에게 다시 되돌아온다 * 라는 생각이 가장 들었고 이 구조가 앞으로 제 프로젝트에서도 재사용될 수 있다는 생각에 설계의 중요성을 더 실감하게 됐습니다.

이번 경험을 바탕으로

• 기능과 UI를 나누는 시선
• context와 상태를 언제, 어떻게 공유할지에 대한 판단
• 조립 가능한 설계 패턴을 염두에 둔 컴포넌트 작성

에 더 깊이 고민하며 성장해 나가고 싶습니다.

참고

https://www.youtube.com/watch?v=fR8tsJ2r7Eg&t=46s https://velog.io/@aeong98/%EC%BB%B4%ED%8C%8C%EC%9A%B4%EB%93%9C-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%ED%8C%A8%ED%84%B4%EC%9C%BC%EB%A1%9C-Select-%EB%A7%8C%EB%93%A4%EA%B8%B0 https://ui.shadcn.com/docs/components/dropdown-menu

띵동이란?

명지대학교 동아리 통합 플랫폼으로, 학생들이 파편화된 동아리 정보와 비효율적인 동아리 업무를 일원화하여 제공하는 서비스입니다.

기존 방식과 개선점

기존에는 동아리 지원 시, 해당 동아리가 올린 외부 폼지(구글 폼 등)로 이동해야 했어요.

💡 개선된 방식 → 띵동 자체 폼지를 제작! 이제 지원하기 버튼을 누르면 띵동 내부 폼지로 이동합니다.

폼지 구성

✅ 기본 질문 (공통)

동아리 지원서 특성상, 모든 지원자가 공통으로 입력해야 하는 항목이 있어요.

• 이름
• 학번
• 학과
• 전화번호
• 이메일

✅ 맞춤형 질문 (시트 추가 기능)

모집 분야가 여러 개인 동아리는 시트를 추가할 수 있어요.

예를 들어, 밴드부 → 보컬, 기타, 드럼 등 각 파트별 추가 질문 가능 사용자가 보컬 선택 → 공통 질문 + 보컬 질문 응답

✅ 질문 유형 (5가지)

• 파일 업로드
• 체크박스 (다중 선택 가능)
• 객관식 (단일 선택)
• 단답형 (300자 이내)
• 서술형 (1000자 이내) 각 질문은 옵션 및 필수 여부를 설정할 수 있습니다.

폼지 관리 기능 (Admin)

Admin 페이지에서** 지원서의 주요 정보**를 관리할 수 있어요.

• 지원서 제목
• 모집 기간
• 지원서 설명
• 면접 여부 설정

개발 난이도 & 복잡도

처음엔 단순히 폼지만 만든다고 생각했는데… 막상 개발하다 보니 엄청난 복잡도가 있었습니다.

-> 하나의 컴포넌트에서 모든 상태 관리 ManageComponent에서

• 새 지원서 생성
• 수정 중인 경우
• 모집 기간 전
• 모집 기간 중 모두 하나의 컴포넌트에서 관리해야 했어요.

초기 코드를 복잡도를 고려하지 않고 작성하면…

• 유지보수 어려움
• 예외 처리 부족 기능 추가 시 구조적으로 수정해야 하는 부분이 많아져서 확장성을 고려한 설계가 정말 중요하다는 걸 느꼈습니다.

이를 고려하지 않고 코드를 짠 결과 제 안타까운 ManageForm컴포넌트를 소개해보겠습니다. . . ☠️

const router = useRouter();
  const [{ token }] = useCookies(['token']);
  const newFormMutation = useNewForm(token);
  const [isEditing, setIsEditing] = useState(false);
  const updateFormMutation = useUpdateForm(setIsEditing);

  const [title, setTitle] = useState(formData?.title ? formData.title : '');
  const [description, setDescription] = useState(
    formData?.description ? formData.description : '',
  );

*폼 내부 요소들을 모두 각각 관리함 *

useEffect(() => {
    if (formData) {
      const updatedFormFields = Object.keys(categorizeFormFields(formData)).map(
        (section) => ({
          section,
          questions: categorizeFormFields(formData)[section].map((field) => ({
            question: field.question,
            type: field.type,
            options: field.options || [],
            required: field.required,
            order: field.order,
            section: field.section,
          })),
        }),
      );

      setFormField(updatedFormFields);
    }
  }, [formData]);

*폼 안에 섹션들을 카테고리화하여 분류함 *

const handleCreateForm = () => {
    if (!title) {
      toast.error('지원서 제목을 입력하여주세요. ');
    }

    if (!description || description.length > 255) {
      toast.error('지원서 설명은 255자 이내로 작성하여주세요.');
      return;
    }

    const formattedPostData = formatFormData();
    newFormMutation.mutate(formattedPostData);
  };

  const handleUpdateForm = () => {
    if (!id || !formData) {
      toast.error('수정할 폼이 존재하지 않습니다.');
      return;
    }
    if (!title) {
      toast.error('지원서 제목을 입력하여주세요. ');
    }

    if (!description || description.length > 255) {
      toast.error('지원서 설명은 255자 이내로 작성하여주세요.');
      return;
    }

    const formattedPostData = formatFormData();

```tsx
    updateFormMutation.mutate({
      token,
      formId: id,
      formData: formattedPostData,
    });
    setIsEditing(false);
    setIsClosed(true);
  };

*형식을 컴포넌트 내에서 모두 같이 관리함 *

  const formatFormData = (): FormData => {
    const formatDate = (date: Date | string | null) => {
      if (!date) return '';
      if (date instanceof Date) return date.toISOString().split('T')[0];
      return new Date(date).toISOString().split('T')[0];
    };

    return {
      title: title.trim(),
      description: description.trim() || null,
      startDate: formatDate(recruitPeriod.startDate),
      endDate: formatDate(recruitPeriod.endDate),
      hasInterview: isChecked ?? false,
      sections: sections,
      formFields: formField.flatMap((section) =>
        section.questions.map(
          (question): FormField => ({
            question: question.question.trim(),
            type: question.type as QuestionType,
            options: question.options || [],
            required: question.required,
            order: question.order,
            section: section.section,
          }),
        ),
      ),
    };
  };

카테고리화해서 관리하기 때문에 이를 다시 해지해줄 format이 필요하게 됨

const isPastStartDate = formData?.startDate
    ? new Date(formData.startDate) < new Date()
    : false;

  const [isClosed, setIsClosed] = useState(formData ? true : false);

  const [isChecked, setIsChecked] = useState(formData?.hasInterview);

  function categorizeFormFields(
    formData: FormData | undefined,
  ): CategorizedFields {
    const categorizedFields: CategorizedFields = {};

    (formData?.sections || []).forEach((section) => {
      categorizedFields[section] = [];
    });

    (formData?.formFields || []).forEach((field) => {
      if (field.section in categorizedFields) {
        categorizedFields[field.section].push(field);
      }
    });

    return categorizedFields;
  }

 const [modiformField, setmodiFormField] = useState(
    Object.keys(categorizeFormFields(formData)).map((section) => ({
      section,
      questions: categorizeFormFields(formData)[section].map((field) => ({
        question: field.question,
        type: field.type,
        options: field.options || ['옵션1'],
        required: field.required,
        order: field.order,
        section,
      })),
    })),
  );

  const [focusSection, setFocusSection] = useState('공통');
  const [sections, setSections] = useState(
    formData ? formData.sections : ['공통'],
  );
  const [recruitPeriod, setRecruitPeriod] = useState<DateRangeType>({
    startDate: null,
    endDate: null,
  });

  useEffect(() => {
    if (formData) {
      setRecruitPeriod({
        startDate: formData.startDate ? new Date(formData.startDate) : null,
        endDate: formData.endDate ? new Date(formData.endDate) : null,
      });
    }
  }, [formData]);

  const baseQuestion: FormField[] = [
    {
      question: '',
      type: 'RADIO',
      options: ['옵션1'],
      required: true,
      order: 1,
      section: '공통',
    },
  ];

  const [formField, setFormField] = useState<SectionFormField[]>(
    formData
      ? modiformField
      : [
          {
            section: '공통',
            questions: [
              {
                question: '',
                type: 'RADIO',
                options: ['옵션1'],
                required: true,
                order: 1,
                section: '공통',
              },
            ],
          },
        ],
  );

  const handleDateChange = (newValue: DateRangeType | null) => {
    setRecruitPeriod(newValue ?? { startDate: null, endDate: null });
  };

  const deleteQuestion = (sectionName: string, questionIndex: number) => {
    setFormField((prev) =>
      prev.map((section) =>
        section.section === sectionName
          ? {
              ...section,
              questions: section.questions
                .filter((_, qIndex) => qIndex !== questionIndex)
                .map((question, newIndex) => ({
                  ...question,
                  order: newIndex + 1,
                })),
            }
          : section,
      ),
    );
  };

  const [modalVisible, setModalVisible] = useState(false);
  const [newSectionName, setNewSectionName] = useState('');

  const handleOpenModal = () => {
    setNewSectionName('');
    setModalVisible(true);
  };

  const onClickEditButton = () => {
    setIsEditing(true);
    setIsClosed(false);
  };

  const onClickCancelButton = () => {
    onReset?.();
  };

  const addQuestion = () => {
    setFormField((prev) =>
      prev.map((section) =>
        section.section === focusSection
          ? {
              ...section,
              questions: [
                ...section.questions,
                {
                  question: '',
                  type: 'RADIO',
                  options: ['옵션1'],
                  required: true,
                  order: section.questions.length + 1,
                  section: focusSection,
                },
              ],
            }
          : section,
      ),
    );
  };

  return (
    <div>
      <Head>
        <title>지원서 템플릿 관리</title>
      </Head>

      <div className="flex items-center justify-between gap-2">
        <div
          onClick={() => router.back()}
          className="flex cursor-pointer items-center gap-1 "
        >
          <Image
            src={arrow_left}
            alt="navigation"
            className="mt-7 w-6 md:mt-11 md:w-9"
          />
          <Heading>지원서 생성</Heading>
        </div>
        <FormEditButtons
          formData={formData}
          isEditing={isEditing}
          isClosed={isClosed}
          isPastStartDate={isPastStartDate}
          handleCreateForm={handleCreateForm}
          onClickEditButton={onClickEditButton}
          onClickCancelButton={onClickCancelButton}
          handleUpdateForm={handleUpdateForm}
        />
      </div>

      <div className="flex w-full items-center justify-end gap-2 pt-10 text-lg font-semibold text-gray-500">
        <div className="relative flex h-[20px] w-[20px] cursor-pointer items-center justify-center">
          <Image
            onClick={() => {
              if (!isClosed) {
                setIsChecked(!isChecked);
              }
            }}
            src={isChecked ? square : emptySquare}
            width={isChecked ? 18 : 22}
            height={isChecked ? 18 : 22}
            className={`object-contain ${
              isClosed ? 'cursor-not-allowed opacity-50' : 'cursor-pointer'
            }`}
            alt="checkBox"
          />
        </div>
        우리동아리는 면접을 보지 않아요!
      </div>

      <div className="flex flex-col gap-4">
        <div className="mt-4 flex flex-row flex-wrap gap-3 md:flex-nowrap">
          <BaseInput
            type="text"
            placeholder={'지원서 제목을 입력해주세요'}
            value={title}
            onChange={(
              e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>,
            ) => setTitle(e.target.value)}
            disabled={isClosed}
          />

          <div className="w-full rounded-lg border pt-1">
            <Datepicker
              value={recruitPeriod}
              useRange={false}
              minDate={new Date(new Date().getFullYear(), 0, 1)}
              maxDate={new Date(new Date().getFullYear(), 11, 31)}
              onChange={handleDateChange}
              placeholder="모집 기간을 설정하세요"
              disabled={isClosed}
            />
          </div>
        </div>
        <TextArea
          placeholder="지원서 설명을 입력해 주세요 (최대 255자 이내)"
          value={description}
          onChange={(
            e: React.ChangeEvent<HTMLTextAreaElement | HTMLInputElement>,
          ) => setDescription(e.target.value)}
          disabled={isClosed}
        />
      </div>

      <div className="mt-6">
        <Sections
          addSection={handleOpenModal}
          focusSection={focusSection}
          sections={sections}
          setFocusSection={setFocusSection}
          isClosed={isClosed}
          formField={formField}
          setFormField={setFormField}
          setSections={setSections}
          baseQuestion={baseQuestion}
        />
        {focusSection == '공통' && <CommonQuestion disabled={true} />}

        {formField
          .filter((item) => item.section === focusSection)
          .map((section) => (
            <div key={section.section}>
              {section.questions.map((question, qIndex) => (
                <Question
                  key={`${section.section}-${qIndex}`}
                  index={qIndex}
                  questionData={question}
                  deleteQuestion={() => deleteQuestion(section.section, qIndex)}
                  setFormField={setFormField}
                  section={section}
                  isClosed={isClosed}
                />
              ))}
            </div>
          ))}
      </div>
      {!isClosed && (
        <button
          onClick={addQuestion}
          className="fixed bottom-24 right-[calc(10vw)] flex items-center justify-center rounded-full bg-blue-500 p-1 shadow-lg transition-all duration-200 hover:bg-blue-600 md:right-[calc(5vw)] lg:right-[calc(2vw)]"
        >
          <Image src={AddForm} width={40} height={40} alt="질문 추가하기" />
        </button>
      )}
    </div>
  );
}

주요 문제점 정리

1. 과도한 상태(state) 관리

• isEditing, isClosed, isPastStartDate 등 권한과 관련된 상태들이 마구잡이로 관리됨
• formData, sections, formFields 등 폼지의 필드들도 각각의 state로 관리됨 결과적으로 수정이 어려운 코드가 되어버림

2. 불필요한 데이터 변환

formData를 섹션별로 객체화하여 관리했는데,

• 막상 섹션 추가하는 경우는 거의 없음
• 게다가 질문도 많아야 10개 이하

• 단순 배열로 관리했으면 더 깔끔했을 것임

3. 검증(Validation) 중복

• Zod를 사용해 Validation을 관리하고 있음에도,
• 별도로 유효성 검사를 추가*하여 코드가 불필요하게 길어짐

4. 컴포넌트 응집도 최악

• ManageForm에서 모든 로직을 떠맡음
• 심지어 "수정 버튼의 상태"까지도 관리함
• 단일 책임 원칙(SRP)을 완전히 위반함.*

5. 재사용 불가능한 거대한 컴포넌트

• Sections, Question, FormEditButtons 등 모든 하위 컴포넌트가 과도한 props를 받음
• isEditing, isClosed, isPastStartDate, handleCreateForm 등 props를 남발하여 유지보수가 힘듦

왜 이렇게 됐을까?

1. "수정"에 대한 설계를 하지 않음

• 처음에는 지원서 생성만 고려하여 개발
• 이후 "수정" 기능 추가 시 무리한 상태 추가 → 코드가 엉망이 됨

2. 초기에는 모집 기간이 지난 폼지도 수정 가능했음

• 이후 "모집 기간이 지난 폼지는 수정 불가" 정책이 추가됨
• 이 과정에서 상태가 더 복잡해짐

3. 수정 기능 추가 시 기존 코드에 덧붙이는 방식으로 작성

• "기존 코드 유지"하면서 기능 추가
• 결과적으로 일관성 없는 상태 관리 + 안좋은 가독성

4. 데이터 구조 설계 실수

• 폼지의 필드를 섹션별 객체로 나눠 관리함
• 하지만 필드가 많아야 10개 이하 → 단순 배열로 관리하는 게 나았음

일단 배포가 되었지만.... 코드의 심각성을 느끼고 리팩토링에 들어갔습니다.

리팩토링

1. 상태 관리 일원화 (formState)

• 기존에는 개별 상태 (title, description 등)를 각각 관리했지만, formState 객체로 통합하여 상태 변경을 일관되게 유지할 수 있음.
• useState를 통해 모든 데이터를 한 곳에서 관리하면서도, 특정 필드만 업데이트하는 방식으로 개선함.

const [formState, setFormState] = useState<FormState>({
    title: formData?.title ?? '',
    description: formData?.description ?? '',
    hasInterview: formData?.hasInterview ?? false,
    sections: formData?.sections ?? ['공통'],
    startDate: formData?.startDate ?? null,
    endDate: formData?.endDate ?? null,
    formFields: formData?.formFields ?? [],
  });

2. mode와 isDisabled, isEditableRegardlessOfPeriod 활용

• mode가 수정(edit)과 뷰(view)를 명확하게 구분하도록 해 모드 전환이 직관적으로 변경했어요

isDisabled와 isEditableRegardlessOfPeriod를 활용하여 사용자의 입력 가능 여부를 상태로 관리하므로, 폼 입력 필드나 버튼을 제어할 때 중복 로직 없이 깔끔하게 처리할 수 있음.

const isPastStartDate = formData?.startDate
    ? new Date(formData.startDate) < new Date()
    : false;

  const [mode, setMode] = useState<'view' | 'edit'>(
    formData == undefined ? 'edit' : 'view',
  );

  const isDisabled = mode === 'view' || isPastStartDate;

  const isEditableRegardlessOfPeriod = mode === 'view';

3. FormEditButtons 컴포넌트로 책임 분리

• 기존에는 ManageForm에서 폼 저장 및 수정 로직을 직접 관리했지만, 이를 FormEditButtons로 이동하여 관심사 분리 (Separation of Concerns, SoC) 를 적용.

• FormEditButtons 내부에서 handleCreateForm, handleUpdateForm, onClickEditButton 등 관련 로직을 모두 처리하도록 구조화.

-> 이렇게 분리하면 ManageForm이 폼 데이터를 렌더링하는 역할에 집중할 수 있어 코드가 더 모듈화됨.

import React from 'react';
import { useCookies } from 'react-cookie';
import { useNewForm } from '@/hooks/api/apply/useNewForm';
import { useUpdateForm } from '@/hooks/api/apply/useUpdateForm';
import { useUpdateFormDeadline } from '@/hooks/api/apply/useUpdateFormDeadline';
import { FormState } from '@/types/form';

type ModeType = 'view' | 'edit';

type Props = {
  formData: FormState | undefined;
  mode: ModeType;
  onReset: () => void;
  setMode: React.Dispatch<React.SetStateAction<ModeType>>;
  formState: FormState;
  id: number | undefined;
  isPastStartDate: boolean;
};

export default function FormEditButtons({
  isPastStartDate,
  formData,
  mode,
  onReset,
  setMode,
  formState,
  id,
}: Props) {
  const [{ token }] = useCookies(['token']);
  const newFormMutation = useNewForm(token);
  const updateFormMutation = useUpdateForm(setMode);
  const updateFormDeadlineMutation = useUpdateFormDeadline();

  const onClickEditButton = () => {
    setMode('edit');
  };
  const handleCreateForm = () => {
    newFormMutation.mutate({
      ...formState,
      startDate: formState.startDate || '',
      endDate: formState.endDate || '',
    });
  };
  const onClickCancelButton = () => {
    setMode('view');
    onReset();
  };
  const handleUpdateForm = () => {
    if (id === undefined) {
      return;
    }
    if (isPastStartDate) {
      updateFormDeadlineMutation.mutate({
        token,
        formId: id,
        endDate: formState.endDate || '',
      });
    } else {
      updateFormMutation.mutate({
        token,
        formId: id,
        formData: {
          ...formState,
          startDate: formState.startDate || '',
          endDate: formState.endDate || '',
        },
      });
    }
  };

  return (
    <div className="mt-7 flex items-center justify-between gap-2 text-lg">
      {!formData ? (
        <button
          className="rounded-xl bg-blue-500 px-4 py-2 font-semibold text-white hover:bg-blue-600"
          onClick={handleCreateForm}
        >
          저장하기
        </button>
      ) : (
        <>
          {mode == 'view' ? (
            <button
              onClick={onClickEditButton}
              className="cursor-pointer rounded-xl bg-blue-100 px-4 py-2 font-semibold text-blue-500 hover:bg-blue-200"
            >
              수정하기
            </button>
          ) : (
            <div className="flex flex-row gap-2">
              <button
                onClick={onClickCancelButton}
                className="rounded-xl bg-gray-100 px-3 py-2 font-semibold text-gray-500 hover:bg-gray-200"
              >
                취소
              </button>
              <button
                onClick={handleUpdateForm}
                className="rounded-xl bg-blue-500 px-4 py-2 font-semibold text-white hover:bg-blue-400"
              >
                저장하기
              </button>
            </div>
          )}
        </>
      )}
    </div>
  );
}

아직도 수정할 부분이 많이 남았지만 일차적으로 구조적인 수정이 끝났습니다 계속해서 리팩토링이 필요해보입니다

더 개선하고 싶은 부분은..

1. 상태관리 최적화 -> formState를 useState로 관리하지만, 여러 필드 업데이트를 처리하면서 setState를 연속 호출하는 경우가 많음. 폼지에서 가장 필요한 부분이 아닐까 싶습니다

2. formFields 업데이트 최적화 현재 formFields는 배열이라 추가/삭제 시마다 setFormState를 새로 호출하는 방식인데,불변성 유지 코드를 더 간결하게 수정하고 싶습니다

3. *불필요한 리렌더링 줄이기 * : 현재 불필요한 리렌더링이 많이 일어나고 있어서 줄이고자 합니다

느낀 점

이번 리팩토링을 진행하면서 단순히 기능을 구현하는 것보다 코드의 구조를 정리하고 유지보수성을 높이는 것이 얼마나 중요한지 다시금 깨닫게 되었습니다. 처음에는 하나씩 기능을 추가하는 방식으로 개발했지만, 점점 코드가 복잡해지면서 유지보수하기 어려워졌고, 새로운 요구사항이 생길 때마다 예상보다 더 많은 수정이 필요하게 되었습니다. 이 과정에서 개발 초기 설계의 중요성을 체감했고, 코드가 확장될 때도 유연하게 대응할 수 있도록 구조를 잡는 것이 필수적이라는 점을 배웠습니다.

특히,

• 상태를 어떻게 관리할 것인지
• 컴포넌트의 역할을 어떻게 나눌 것인지
• 어떤 로직을 어디에서 담당하도록 할 것인지 이러한 고민을 깊이 해보면서 단순히 "동작하는 코드"가 아닌 잘 설계된 코드가 무엇인지 고민하는 계기가 되었습니다.

리팩토링을 통해 관심사를 분리하고, 불필요한 상태 관리를 줄이고, 코드의 가독성을 높이며, 유지보수가 쉬운 구조로 개선할 수 있었지만, 여전히 더 다듬을 부분이 남아 있다고 생각합니다.

"기능 구현"을 넘어서 "설계와 유지보수"까지 고려하는 개발자가 되어야겠다는 목표를 다시 한번 되새기게 된 리팩토링이었습니다.

FSD 패턴(FSFP, Feature-Sliced Design Pattern) 이란?

FSD 패턴은 프론트엔드 프로젝트를 계층적으로 구성하여 유지보수성을 높이는 아키텍처 패턴입니다.
기존 폴더 구조보다 역할별 분리를 강조하며, 프로젝트가 커질수록 폴더 구조가 명확해지고, 코드 간 의존성이 줄어드는 장점이 있습니다.

FSD 패턴의 주요 폴더 구조

app 전역 설정 담당 (_app , _document 등 로직이 초기화 되는 곳) Provider, Router, client 같은 컴포넌트들이 slice 된다. processes (선택) 회원가입 등과 같이 여러 단계로 이루어진 프로세스를 처리한다. 특정한 상태를 기반으로 여러 화면 또는 로직이 포함된 작업 processes/ ├── registration/ │ ├──** model/ ** // 회원가입 상태 및 로직 관리 │ ├── ui/ // 회원가입 관련 화면 및 컴포넌트 │ └── index.ts └── checkout/ pages → 메인페이지 URL 라우트에 매핑되는 페이지가 포함된다. widgets (선택) → 헤더, 내용별 컨텐츠 여러 feature를 결합해 특정 화면 단위의 구성 요소를 정의, 페이지에 사용되는 독립적인 UI 컴포넌트 features (선택) → 폼, 액션버튼 행동, 비즈니스 가치를 전달하는 사용자 시나리오와 기능 entities → 주요 데이터 모델과 그와 관련된 상태/로직, 비즈니스 엔티티 shared →공유 컴포넌트

이제 패턴에 대해 어느정도 이해를 했으니 Next.js에 적용하려고 했다 근데 ..

Next.js App Router와 FSD 패턴 충돌 문제

Next.js 13.4부터 App Router 방식이 도입되면서 
기존 pages/ 라우팅 방식과 app/ 폴더 방식이 혼용될 수 있는 문제가 발생합니다.

FSD 패턴에는 pages/ 폴더가 존재하는데, Next.js에도 pages/가 존재하기 때문에 폴더 충돌 가능성이 발생한다 Next.js App Router 방식에서는 app/ 폴더를 루트로 두어야 하지만, FSD 패턴에서도 app/ 폴더가 존재할 수 있어 혼동 가능한 것이다

해결 방법

공식문서를 통해서 해결 방법을 찾아보았다

Next.js App Router를 루트로 두고 FSD 페이지 구조를 src/ 폴더 내부에 배치 app/ 폴더를 루트에 유지하고, pages/ 폴더를 FSD 내부에서 관리하는 방식이 권장된다 next.js에서 FSD패턴 가이드

📦 프로젝트 루트
 ├── 📂 app/  (Next.js App Router 전용 폴더)
 │    ├── 📂 src/
 │    │    ├── 📂 pages/   (🚀 FSD 패턴에 맞춘 페이지 구조)
 │    │    ├── 📂 processes/
 │    │    ├── 📂 widgets/
 │    │    ├── 📂 features/
 │    │    ├── 📂 entities/
 │    │    ├── 📂 shared/
 │    │    ├── index.ts
 │    ├── layout.tsx  (Next.js의 App Router 전용)
 │    ├── page.tsx  (Next.js의 기본 페이지)
 │    └── global.css
 ├── 📂 public/
 ├── 📂 styles/
 ├── 📂 components/
 ├── next.config.js
 ├── tsconfig.json
 └── package.json

해당 해결책으로 FSD패턴을 적용하기로 했습니다

그래서 우리는 기존 프로젝트의 마이그래이션으로 FSD패턴을 쓰려고 했는가

1. 프로젝트 유지보수가 쉬워짐 기존 Next.js의 라우팅 방식 (pages/ 중심)에서는 컴포넌트의 역할이 모호해질 수 있음. FSD 패턴을 적용하면 각 기능과 데이터 모델이 명확하게 분리되어 유지보수가 편리함.

-> 기존 구조에서는 하나의 작업에서 여러 폴더 계층을 오가야되는 상황 해결

2. 페이지별 독립적인 관리 가능 pages/ 폴더가 혼합되지 않고, 각 기능을 독립적인 feature로 관리할 수 있음. 하나의 페이지에서 필요한 기능만 로드하여 모듈화가 쉬워짐.

3. 의존성 관리가 쉬워짐 상위 폴더에서 하위 폴더만 import 가능하도록 규칙을 강제하면, 순환 의존성 문제를 예방할 수 있음. ESLint 규칙을 적용하면 코드 규칙을 자동으로 검사할 수 있으니 사용해보면 좋을 듯 !!

ESLint FSD 규칙 적용 예시

"overrides": [
  {
    "files": ["src/**/*.ts", "src/**/*.tsx"],
    "rules": {
      "fsd-layer-imports/path-checker": "error",
      "fsd-layer-imports/public-api-imports": "error"
    }
  }
]

우려되는 점 & 해결책

1. 우선순위가 꼬일 가능성 문제: 프로젝트에서 어떤 폴더를 기준으로 관리해야 할지 헷갈릴 수 있음.

-> app/을 Next.js의 루트로 유지하되, FSD 패턴을 src/ 내부에서 유지하여 혼동을 방지.

2. 라우팅이 꼬일 가능성 문제: Next.js의 App Router와 FSD의 pages/ 구조가 섞이면서 라우팅 우선순위 문제가 발생할 수 있음.

-> app/ 라우터 내부에서 FSD 패턴을 적용하고, pages/ 폴더를 루트가 아닌 src/ 내부에 배치하여 충돌을 방지.

위의 이유로 이번 마이그레이션에서는 FSD패턴을 적용하기로 하였습니다.

next 앱라우팅 환경이고 useRouter()를 이용한 동적라우팅 방식을 사용하였다.

개발 후 스토리북에 업로드 하려하자 이런 오류가 난다. 🤮

Error: invariant expected app router to be mounted

공식문서에서 제시한 해결책을 알아보자

https://storybook.js.org/docs/get-started/frameworks/nextjs

Next.js 프로젝트가 app모든 페이지에 디렉토리를 사용하는 경우(즉, 디렉토리가 없는 경우 ), 파일에서 매개 pages변수를 설정하여 모든 스토리에 적용할 수 있습니다. nextjs.appDirectorytrue.storybook/preview.js|ts

Sol ⭐️ appDirectory:true 를 추가하니 해결됐다.

*Storybook에 tailwind가 적용되지 않은 모습이다. *

Sol ⭐️ storybook/preview.ts에 밑에 해당 코드를 작성 하면 끝이다 !!!

import '../src/app/style/globals.css';

타입 확장은 기존 타입을 사용해서 새로운 타입을 정의하는 것을 말한다. 기본적으로 타입스크립트에서는interface, type 키워드를 사용해서 타입을 정의한다. 뿐만 아니라 타입을 받아오는 제네릭과 클래스에서도 타입을 확장하거나 제한할 수 있다

1. 타입(Type)을 확장하거나 제한하는 경우

TypeScript의 type 키워드를 사용하여 정의된 고정된 타입입니다.

확장 혹은 제한 방식 : 유니온 타입(Union Type), 인터섹션 타입(Intersection Type), 타입 별칭(Type Alias) 등을 사용

언제 타입을 사용해야 하나?

• 고정된 타입 조합을 만들고 싶을 때 (유니온, 인터섹션).
• 단순히 속성을 추가하거나 제거하여 새로운 타입을 만들고 싶을 때.
• 타입 유틸리티 (Partial, Pick, Omit, Exclude 등)로 타입을 조작하고 싶을 때.

type Animal = {
  name: string;
};

type Dog = Animal & { breed: string }; // 인터섹션 타입으로 Animal을 확장
type Pet = Animal | Dog; // 유니온 타입으로 Animal과 Dog를 조합

// 타입 제한: 특정 속성 제거
type Person = {
  name: string;
  age: number;
  location: string;
};

type PersonWithoutLocation = Omit<Person, 'location'>; // location 속성 제거

2. 인터페이스(Interface)를 확장하거나 제한하는 경우

인터페이스는 TypeScript의 컨텍스트 내에서만 존재하는 가상 구조입니다. TypeScript 컴파일러는 타입 체크 목적으로만 인터페이스를 사용합니다.

• 인터페이스의 확장방식 : 상속 , 선언적 확장

✚ 인터페이스는 추상클래스로 사용됩니다. 메소드의 형태만 선언해서 인터페이스를 정의하고, 이후에 클래스를 정의할 때 implements 키워드를 사용하면서 이 인터페이스를 지정하면, 이 클래스는 추상함수로 선언된 메소드를 받아들여야 합니다.

언제 인터페이스를 사용해야 하나?

• 객체의 구조를 정의하고 이를 확장해야 할 때.
• 확장 가능성이 있는 타입을 정의할 때, 특히 외부 모듈과 협업할때 주로 사용
• 클래스와 함께 사용하여 구조를 공유하거나 상속 구조를 만들 때.

interface Animal {
  name: string;
}

interface Dog extends Animal {
  breed: string;
}

const myDog: Dog = {
  name: "Buddy",
  breed: "Golden Retriever",
};

// 인터페이스 확장
interface Person {
  name: string;
  age: number;
}

// 선언적 확장: 기존 인터페이스에 속성 추가
interface Person {
  location: string;
}

const person: Person = {
  name: "Alice",
  age: 30,
  location: "New York",
};

3. 제네릭(Generic)을 사용하여 확장하거나 제한하는 경우

제네릭은 타입을 파라미터화하여 유연하게 여러 타입을 처리할 수 있도록 합니다.

• 제네릭의 타입 확장과 제한 :extends 키워드

언제 제네릭을 사용?

• 다양한 타입을 처리해야 할 때: 함수, 클래스, 인터페이스 등에서 다형성 제공.
• 타입을 명확히 제약하거나 확장해야 할 때 (extends, T extends keyof U 등).
• 반환 타입과 입력 타입이 동적으로 결정되어야 할 때.

// 제네릭으로 타입을 제한
function getValue<T extends { name: string }>(obj: T): string {
  return obj.name;
}

getValue({ name: "Alice" }); // 정상
// getValue({ age: 30 }); // 오류: 'name' 속성이 없기 때문

// 제네릭을 사용한 인터페이스
interface Box<T> {
  value: T;
}

const numberBox: Box<number> = { value: 123 };
const stringBox: Box<string> = { value: "Hello" };

4. 클래스 상속 (extends)을 통한 타입 확장

클래스 상속은 새로운 클래스를 정의할 때 기존 클래스의 속성과 메서드를 재사용하여 확장하는 가장 기본적인 방법

사용 상황:

• 기본 클래스의 기능을 확장하거나, 기본 기능을 유지하면서 새로운 기능을 추가해야 할 때.
• 여러 클래스 간의 공통 기능을 부모 클래스로 추출하여 재사용할 때.

interface Movable {
  move(): void;
}

interface Barkable {
  bark(): void;
}

class Dog implements Movable,Barkable {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  move() {
    console.log(`${this.name} is moving.`);
  }

  bark() {
    console.log(`${this.name} barks.`);
  }
}

const dog = new Dog('Buddy');
dog.move(); // Buddy is moving.
dog.bark(); // Buddy barks.

추상 클래스 (abstract)를 통한 타입 확장과 제한

추상 클래스는 공통된 기능을 가진 클래스들의 기본 형태를 정의하고, 구체적인 구현은 서브클래스에서 하도록 강제하는 방식입니다.

사용 상황:

• 기본적인 메서드와 속성을 제공하면서, 구체적인 구현은 자식 클래스에 맡기고 싶을 때.
• 인스턴스화를 허용하지 않으면서, 상속을 통해 공통 기능을 공유해야 할 때.

abstract class Animal {
  abstract makeSound(): void;

  move() {
    console.log('Moving...');
  }
}

class Dog extends Animal {
  makeSound() {
    console.log('Woof!');
  }
}

const dog = new Dog();
dog.makeSound(); // Woof!
dog.move(); // Moving...

상황으로 생각하기

상황

도서관에서 책을 분류하고 관리하는 시스템을 설계함.

📚 장르 : 문학, 과학, 역사, 미술 
💝 사은품 종류 : 책갈피, 포스터, 스티커 
💰 결재 상태 : 결재 됨, 안됨

[타입 영역]

도서관의 책은 다양한 장르가 있으며 책마다 사은품이 있을 수도 있고 없을 수도 있다

[처리 영역]

사은품이 있는 경우→ 결제 시 계산 포스기에서 사은품을 선택할 수 있는 옵션이 나타나야 한다

계산이 완료된 책→ 계산 완료된 상품으로 표시되어야 하며, 이 정보는 포스 시스템에 반영

사용자는 결제 방법(카드, 현금 등)을 선택할 수 있으며, 결제 완료 후 사은품에 존재 여부에 따라 추가적인 결제 흐름과 마지막엔 가격이 나온다

타입 영역

장르와 사은품 결재 상태는 특정형태로 유지되어서 타입을 사용

// 책의 장르를 정의
type Genre = '문학' | '과학' | '역사' | '미술';

// 사은품 종류를 정의
type GiftType = '책갈피' | '포스터' | '스티커';

// 결제 상태를 정의
type PaymentStatus = 'paid' | 'unpaid';

인터페이스(Interface) 영역

인터페이스는 책의 구조를 정의하며, 사은품의 유무와 결제 상태와 같은 속성을 추가로 확장하여 사용할 수 있다.

// 책의 구조 정의 - 사은품과 결제 상태를 포함하여 타입 제한
interface Book {
  title: string;
  genre: Genre;
  price: number;
  gift?: GiftType; // 사은품은 있을 수도, 없을 수도 있음
  status: PaymentStatus;
}

// 결제 처리와 관련된 인터페이스
interface Payable {
  calculatePrice(): number;
  showPaymentOptions(): void;
}

제네릭 클래스 영역

제네릭을 사용하여 사은품의 유무와 결제 여부를 처리한다. : 제네릭을 통해 다양한 결제 상태와 사은품 여부를 쉽게 확장하거나 조합

추상 클래스는 기본적으로 책과 관련된 메서드를 정의하며, 실제 계산 로직은 서브클래스에서 구현

// 추상 클래스 정의 - 결제 로직
// payable + Book타입을 확장하는 T
abstract class LibraryItem<T extends Book> implements Payable {
  protected book: T;

  constructor(book: T) {
    this.book = book;
  }

  // 입장 조건: 모든 서브클래스는 이 메서드를 구현해야 함
  abstract calculatePrice(): number;

  showPaymentOptions(): void {
    console.log('카드와 신용카드로 결제가 가능합니다 ');
  }

  showPaidStatus() {
    if (this.book.status === 'paid') {
      console.log('결제가 이미 완료됨');
    } else {
      console.log('결제 아직 안됨');
    }
  }
}

// 제네릭 클래스 - 사은품과 결제 여부에 따른 처리
class ProcessBook<T extends Book> extends LibraryItem<T> {
  // 입장 조건: Book 타입을 확장하는 T 타입을 처리
  calculatePrice(): number {
    if (this.book.gift) {  //추상클래스 사용
      console.log(`사은품포함 : ${this.book.gift}`);
      return this.book.price + 5; // 사은품이 있을 경우 추가 비용
    }
    return this.book.price;
  }//사은품에 따른 가격 수정

  displayBookDetails() {
    console.log(`Title: ${this.book.title}, Genre: ${this.book.genre}`);
    this.showPaidStatus();
  }
}

// 특정 책 인스턴스 생성 및 처리
const myBook: Book = {
  title: '노인과바다',
  genre: '문학',
  price: 20,
  gift: '책갈피',
  status: 'paid',
};

//LibraryItem의 생성자 호출: ProcessBook 클래스는 LibraryItem 추상 클래스를 상속받아
//ProcessBook의 생성자는 먼저 LibraryItem의 생성자를 호출하여 this.book을 초기화
//LibraryItem의 생성자에서 전달된 myBook -> this.book에 할당. 
const processedBook = new ProcessBook(myBook);
processedBook.displayBookDetails(); // 책 정보 및 결제 상태 표시
console.log(`Total price: ${processedBook.calculatePrice()}원`); // 총 금액 계산

🤔 퀴즈

타입(Type) 확장 방식으로 사용되는 것 중 맞는 것은?

1. extends 키워드
2. 유니온 타입
3. 추상 클래스

• 정답
  1. 유니온 타입

제네릭(Generic)의 타입에서 extends 키워드의 역할은 무엇인가요?

• 정답

  제네릭 타입의 범위를 제한하거나 특정 조건을 부과합니다.

1. 타입 공간

   • 타입 공간의 심벌은 타입을 정의하고 참조할 때 사용됩니다. 이 공간에서 심벌은 타입을 의미하며, 컴파일 시점에 타입 검사를 위해 사용

     number, string, boolean, User 등

2. 값 공간

   • 값 공간의 심벌은 실제 런타임에 사용되는 값입니다. 이 공간의 심벌은 코드가 실행될 때 실제 메모리에서 사용

     숫자 5, 문자열 "hello", 객체 { name: "Alice" } 등

타입과 값의 구분 코드

// 타입 공간의 심벌
type User = {
  name: string;
  age: number;
};

// 값 공간의 심벌
const user: User = {
  name: "youjin",
  age: 21,
};

// 타입 공간의 심벌 사용 예시
function greet(user: User): string {
  return `Hello, ${user.name}`;
}

// 값 공간의 심벌 사용 예시
console.log(greet(user)); // 출력: Hello, youjin

User는 타입 공간에서 사용되며, 데이터의 구조를 정의한다

user는 값 공간에서 사용 되는 데이터이다

타입과 값의 구분 코드

// 타입 공간의 심벌
type User = {
  name: string;
  age: number;
};

// 값 공간의 심벌
const user: User = {
  name: "youjin",
  age: 21,
};

// 타입 공간의 심벌 사용 예시
function greet(user: User): string {
  return `Hello, ${user.name}`;
}

// 값 공간의 심벌 사용 예시
console.log(greet(user)); // 출력: Hello, youjin

User는 타입 공간에서 사용되며, 데이터의 구조를 정의한다

user는 값 공간에서 사용 되는 데이터이다

타입과 값의 구분을 위한 규칙

type T1 = 'string literal';
type T2 = 123;

const V1 = 'string literal';
const V2 = 123;

T1과 T2는 타입을 정의하고,

V1과 V2는 실제 값을 저장하는 심벌입니다

typeof 연산자의 타입 공간과 값 공간에서의 사용 차이

type T1 = typeof V1; // 타입: 'string'
type T2 = typeof V2; // 타입: 'number'

const v1 = typeof V1; // 값: "string"
const v2 = typeof V2; // 값: "number"

• type T1 = typeof V1;는 타입 공간에서의 사용으로, V1의 타입을 참조합니다.
• const v1 = typeof V1;는 값 공간에서의 사용으로, V1의 실제 타입을 문자열로 반환합니다.

클래스의 타입과 값 구분

1. 타입 공간에서의 클래스

   • 타입으로서의 클래스는 해당 클래스의 인스턴스 타입을 정의합니다. 즉, 클래스를 타입처럼 사용하여 변수의 타입을 지정하거나, 제네릭 타입 제약조건으로 사용할 수 있습니다.

     타입 선언, 함수 파라미터의 타입으로 사용.

2. 값 공간에서의 클래스

   • 값으로서의 클래스는 실제로 런타임 시점에 존재하는 생성자 함수로, 객체를 생성하거나 instanceof 연산을 통해 인스턴스인지 검사할 때 사용됩니다.

     new 키워드를 사용해 객체 생성, instanceof로 타입 검사.

class Person {
  name: string;
  constructor(name: string) {
    this.name = name;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

// 타입 공간에서 사용
let personType: Person; // 타입으로 사용: Person 클래스의 인스턴스를 기대함

// 값 공간에서 사용
const personValue = new Person("Name"); // 값으로 사용: 객체 생성
personValue.greet(); // 출력: Hello, my name is Name
console.log(personValue instanceof Person); // true

타입 공간 (let personType: Person): Person은 타입으로 사용되어 personType 변수는 Person 타입의 인스턴스만 가짐

값 공간 (new Person("Name")): Person은 생성자로 사용되어 새로운 객체를 만든다

// 기본 클래스 Person 정의
class Person {
  name: string;
  constructor(name: string) {
    this.name = name;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

// Person을 확장하는 Age 클래스
class Age extends Person {
  age: number;
  constructor(name: string, age: number) {
    super(name);
    this.age = age;
  }

  greetWithAge() {
    console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
  }
}

// 타입 공간에서의 사용 예시
let personType: Person; // Person 타입의 인스턴스를 기대
let ageType: Age; // Age 타입의 인스턴스를 기대

// personType은 Person의 인스턴스를 참조
personType = new Person("심유진");
personType.greet(); // 출력: Hello, my name is 심유진

// ageType은 Age의 인스턴스를 참조
ageType = new Age("심슨", 25);
ageType.greetWithAge(); // 출력: Hello, my name is 심슨 and I am 25 years old.

// personType에 Age 인스턴스를 할당하는 것도 가능 (Age는 Person을 확장하므로)
personType = new Age("영희", 30);
personType.greet(); // 출력: Hello, my name is 영희

// 합집합 타입 사용
type PersonOrAge = Person | Age;

let personOrAge: PersonOrAge;

// Person 타입 할당
personOrAge = new Person("Alice");
personOrAge.greet(); // 출력: Hello, my name is Alice

// Age 타입 할당
personOrAge = new Age("Bob", 40);
if (personOrAge instanceof Age) {
  personOrAge.greetWithAge(); // 출력: Hello, my name is Bob and I am 40 years old.
} else {
  personOrAge.greet(); // 해당 부분은 Age가 아닌 Person 인스턴스인 경우에만 실행
}

// 값 공간에서의 사용
const personValue = new Person("Tom"); // 값으로 사용: 객체 생성
personValue.greet(); // 출력: Hello, my name is Tom
console.log(personValue instanceof Person); // true

const ageValue = new Age("Jenny", 28); // Age 객체 생성
ageValue.greetWithAge(); // 출력: Hello, my name is Jenny and I am 28 years old.
console.log(ageValue instanceof Age); // true
console.log(ageValue instanceof Person); // true (Age는 Person을 확장했기 때문에)

두 공간(타입, 값)에서 다른 의미를 가지는 코드 패턴

1. this 키워드

• 값으로 사용: 현재 객체를 참조
• 타입으로 사용: 현재 클래스 타입을 참조하며, 다형성(polymorphic this)으로 사용된다

class Animal {
  name: string;
  constructor(name: string) {
    this.name = name;
  }

  // 값으로 사용: 현재 객체를 참조
  setName(name: string): this {
    this.name = name; // this는 현재 객체를 참조
    return this;
  }
}

class Dog extends Animal {
  breed: string;

  constructor(name: string, breed: string) {
    super(name);
    this.breed = breed;
  }

  // 타입으로 사용: this 타입을 반환하여 메서드 체인 
  setBreed(breed: string): this {
    this.breed = breed;
    return this;
  }
}

const myDog = new Dog("Rex", "Labrador")
  .setName("Buddy") // 메서드 체인
  .setBreed("Golden Retriever");

console.log(myDog); // Dog { name: 'Buddy', breed: 'Golden Retriever' }

//setName 메서드를 호출하면 Animal 타입이 아닌 Dog 타입의 인스턴스가 반환
//때문에 setName 메서드 호출 후에 setBreed 메서드를 호출 가능

2. &와 | 연산자

• 값으로 사용 : 비트 연산자로 AND와 OR 연산을 수행한다
• 타입으로 사용 : 타입 시스템에서 인터섹션(&)과 유니온(|) 타입을 정의한다

// 값으로 사용: 비트 연산
const bitwiseAnd = 5 & 3; // 0101 & 0011 = 0001 (1)
const bitwiseOr = 5 | 3;  // 0101 | 0011 = 0111 (7)
console.log(bitwiseAnd, bitwiseOr); // 출력: 1 7

// 타입으로 사용: 인터섹션(&)과 유니온(|)
type Cat = { purrs: boolean };
type Dog = { barks: boolean };
type Pet = Cat & Dog; // 인터섹션 타입: 두 타입의 모든 속성을 가짐

let myPet: Pet = { purrs: true, barks: true }; // Cat과 Dog의 속성을 모두 가짐

type AnimalType = Cat | Dog; // 유니온 타입: Cat 또는 Dog 중 하나의 속성을 가짐

let anotherPet: AnimalType = { purrs: false }; // Cat 타입으로 사용 가능

3. const

• 값으로 사용: 변수를 선언할 때 사용하며, 값은 변경되지 xx
• 타입으로 사용 (as const): 리터럴 값의 타입을 정확하게 고정시키거나 추론된 타입을 변경

// 값으로 사용: 변경 불가능한 변수 선언
const MAX_COUNT = 100;
// MAX_COUNT = 200; // 오류: 상수는 재할당할 수 없음

// 타입으로 사용: 리터럴 값을 고정하여 추론
const pet = {
  type: "cat",
  color: "black",
} as const; // pet의 타입이 { type: "cat"; color: "black"; }으로 고정됨

function describePet(pet: { type: "cat" | "dog"; color: string }) {
  console.log(`This ${pet.type} is ${pet.color}.`);
}

describePet(pet); // "This cat is black."

4. extends

• 값으로 사용 (class A extends B): 클래스 상속을 통해 B 클래스의 기능을 A 클래스에 확장
• 타입으로 사용 (interface A extends B): 인터페이스 상속을 통해 A 인터페이스가 B의 타입을 확장
• 제네릭 타입 한정자 (Generic): 제네릭 타입에서 T가 특정 타입을 확장하도록 제한

// 값으로 사용: 클래스 상속
class Vehicle {
  speed: number = 0;
  drive() {
    console.log(`Driving at ${this.speed} km/h`);
  }
}

class Car extends Vehicle {
  setSpeed(speed: number) {
    this.speed = speed;
  }
}

const myCar = new Car();
myCar.setSpeed(60);
myCar.drive(); // 출력: Driving at 60 km/h

// 타입으로 사용: 인터페이스 상속
interface Animal {
  legs: number;
}

interface Bird extends Animal {
  canFly: boolean;
}

const sparrow: Bird = { legs: 2, canFly: true };

// 제네릭 타입 한정자로 사용
function logLength<T extends { length: number }>(item: T) {
  console.log(item.length);
}

logLength([1, 2, 3]); // 출력: 3

5. in

• 값으로 사용 (for (key in object)): 객체의 속성을 순회할 때 사용한다
• 타입으로 사용 (매핑된 타입): 타입 시스템에서 키의 집합을 기반으로 새로운 타입을 정의할 때 사용한다

// in 연산자의 값과 타입 공간에서의 사용

// 값 공간에서의 사용: 객체 순회
const obj = { a: 1, b: 2, c: 3 };
for (const key in obj) {
  console.log(key); // "a", "b", "c"
}

// 타입 공간에서의 사용: 매핑된 타입
type Keys = 'name' | 'age'; //'name' 또는 'age'의 문자열 리터럴 타입을 가짐
type User = { [K in Keys]: string }; // User 타입은 { name: string; age: string; }
const user: User = { name: "Alice", age: "30" };

퀴즈

1. 다음 코드에서 타입 공간과 값 공간의 심벌을 구분해주세요

class Car {
  model: string;
  constructor(model: string) {
    this.model = model;
  }
}

type Vehicle = Car; //1

const myCar = new Car("Tesla"); //2

console.log(myCar instanceof Car); //3

• 정답

  type Vehicle = Car;:

  • 타입 공간: Vehicle은 type 키워드를 사용하여 Car 타입을 별칭으로 지정한 심벌입니다

  • const myCar = new Car("Tesla");*:

  • 값 공간: myCar는 실제로 메모리에 할당되는 Car 클래스의 인스턴스입니다ㅁ

  • console.log(myCar instanceof Car);*

  • 값 공간: instanceof는 값 공간에서만 동작하는 연산자로, myCar가 Car의 인스턴스인지 검사합니다. 여기서 Car는 값 공간에서 생성자 함수로 사용됐습니다

2. instanceof가 타입을 검사하는지 값을 검사하는지 말해보세요

class Shape {
  sides: number;
  constructor(sides: number) {
    this.sides = sides;
  }
}

const square = new Shape(4);

console.log(square instanceof Shape); 

• 정답

  값 공간에서의 검사:

  square instanceof Shape는 square가 Shape 클래스의 인스턴스인지 확인한다

  instanceof는 square 객체의 프로토타입 체인을 검사하여 Shape의 프로토타입이 포함되어 있는지 확인함

https://toss.tech/article/typescript-type-compatibility글과 Effective 타입스크립트 책을 보고 정리 하였습니다 !

덕 타이핑 (Duck Typing)

덕 타이핑은 "만약 어떤 것이 오리처럼 걷고, 헤엄치고, 꽥꽥거린다면 그것은 오리일 것이다"라는 철학에서 유래된 개념입니다. 즉, 객체가 어떤 인터페이스나 타입을 명시적으로 구현하지 않더라도, 해당 객체가 요구되는 기능을 모두 구현하고 있다면 그 객체를 사용할 수 있다는 의미입니다.

타입스크립트에서도, 객체가 특정 속성과 메서드를 가지고 있다면 타입 선언 없이도 그 객체가 예상대로 동작할 수 있습니다. 이것이 타입스크립트의 구조적 서브타이핑 방식과 연결됩니다.

핑 타이핑 (Ping Typing)

덕 타이핑에서 아이디어를 차용해, 어떤 글자 뒤에 "핑"을 붙이면 그 글자가 <<캐치! 티니핑>>의 멤버가 된다는 발상을 농담처럼 표현해보았습니다

“만약 어떤 글자 뒤에 핑이라고 붙이면 << 캐치! 티니핑>>의 멤버가 된다… ? → 핑 타이핑 ? “

function isTiniPing(name: string): boolean {
  return name.endsWith('핑');
}

const name = "하츄핑";
if (isTiniPing(name)) {
  console.log(`${name}은(는) 티니핑 멤버입니다!`);
}

🤔 그렇다면 서브타이핑의 종류에는 어떤 것이 있을까요 ??

서브타이핑의 종류

타입의 계충 구조에서 한 타입이 다른 타입의 부분 집합일 때 발생하는 타입 관계

1. 명목적 서브타이핑(nominal subtyping) → java, C#

타입 정의 시에 상속 관계임을 명확히 명시한 경우에만 타입 호환을 허용하는 것입니다.

• 개발자의 명확한 의도를 반영할 수 있다
• 오류 발생할 가능성 배제

2. 구조적 서브타이핑(structural subtpying) → TS

상속 관계가 명시되어 있지 않더라도 객체의 프로퍼티를 기반으로 사용처에서 사용함에 문제가 없다면 타입 호환을 허용하는 방식

• 객체의 프로퍼티를 체크해주는 과정 수행
• 상속관계를 명시해줄 필요가 없음

🤔 타입스크립트에서 사용하는 구조적 타이핑의 예시를 알아보겠습니다

구조적 타이핑의 예시

: 봉인된 타입과 정확한 타입

자바스크립트와 타입스크립트는 기본적으로 타입 시스템이 열려있는(open) 상태

즉, 객체가 타입에 명시된 속성 외에도 추가적인 속성을 가질 수 있으며, 타입 체크는 해당 속성들만 맞는지를 확인합니다

• 해당 속성들만 맞는지만 확인

interface Vector2D {
  x: number;
  y: number;
}

function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y);
}

interface NamedVector {
  name: string;
  x: number;
  y: number;
}

//calculateLength 함수에 NamedVector 타입의 객체 v를 전달할 수 있다.
// 왜냐하면, v가 Vector2D에서 요구하는 x와 y 속성을 가지고 있음.
const v: NamedVector = { x: 3, y: 4, name: "zee" };
console.log(calculateLength(v)); // 5

• 객체가 2개의 속성밖에 못가지지만 , 3개의 속성을 추가하여 무시됨

interface Vector2D {
  x: number;
  y: number;
}

const vector = { x: 3, y: 4, z: 5 }; // z는 추가적인 속성

function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y);
}

console.log(calculateLength(vector)); // 5, z는 무시됨

• 객체가 여러 속성을 가질 수 있지만, 필요한 속성만 이용함

interface Point3D {
  x: number;
  y: number;
  z: number;
}

function calculate2DLength(point: { x: number; y: number }) {
  return Math.sqrt(point.x * point.x + point.y * point.y);
}

const point3D: Point3D = { x: 5, y: 12, z: 7 };

console.log(calculate2DLength(point3D)); // 13

type이름이 티니핑인데 속성이 눈코입이면 눈코입 속성을 가진 다른 캐릭터 또한 들어올 수 있게됩니다 때문에 type 속성에는 들어오지만

• 명확한 경우
• 애매한 경우

가 공존할 수 있게 됩니다 👉 그래서 타입 구분을 통해 이를 해결할 수 있습니다

타입 구분 방법

1. 특정 경우에만 해당하는 변수를 타입으로 지정

: 캐릭터 속성에서 티니핑 타입을 정의하여 구분할 수 있습니다

// 기본 캐릭터 속성 정의
type Character = {
  strength: number;
  agility: number;
  intelligence: number;
};

// 티니핑 타입 정의 (Character에 추가 속성 포함)
type 티니핑 = Character & {
  characterBrand: string;
};

// 티니핑 객체 예시
const character1: 티니핑 = {
  strength: 29,
  agility: 48,
  intelligence: 13,
  characterBrand: '캐치! 티니핑'
};

// 일반 캐릭터와 티니핑 캐릭터 구분
const character2: Character = {
  strength: 25,
  agility: 40,
  intelligence: 15
};

console.log(character1.characterBrand); // "캐치! 티니핑"

그렇다면 타입이 아닌 character2에만 가능한 characterBrand 프로퍼티 추가를 한다면 ?

const character2 = Character({
  strength: 12;
  agility: 32;
  intelligence: 434;
  characterBrand: '캐치! 티니핑'
})                                  /** 타임검사 결과 : 오류 있음 */

//다음처럼 함수에 들어온 인자가 fresh하면 해당 함수에서만 사용되고 다른 곳에서 사용되지 않기에 오류로 지정 

TypeScript Type Checker는 구조적 서브타이핑을 기반으로 타입 호환을 판단하되, Freshness에 따라 예외를 둔다고 합니다.

2. Branded type ( 프로퍼티 추가 )

의도적으로 __brand 와 같은 프로퍼티를 추가시켜, 개발자가 함수의 매개변수로 정의한 타입 외에는 호환이 될 수 없도록 강제하는 기법

2-1 . 타입에 고유한 식별자를 부여하는 방식

: 브랜트 타입에 브랜드 속성을 '캐치! 티니핑’으로 부여하여 티니핑 타입을 정의할 수 있습니다

type Brand<K, T> = K & { __brand: T };

// 티니핑 타입 정의
type 티니핑 = Brand<{
  strength: number;
  agility: number;
  intelligence: number;
}, '캐치! 티니핑'>;

// 티니핑의 능력치를 계산하는 함수
function calculatePower(character: 티니핑): number {
  return character.strength * 2 + character.agility * 1.5 + character.intelligence * 3;
}

// 정석적인 방법으로 브랜디드 타입 사용
const brandedCharacter2 = {
  strength: 29,
  agility: 48,
  intelligence: 13,
  __brand: '캐치! 티니핑' as const // __brand 속성 추가로 명확하게 타입 지정
};

console.log(calculatePower(brandedCharacter2)); // OK

2-2. 함수에서의 타입 제한

: 어떤 글자가 들어올 때 핑으로 끝나더라도 타입을 통해 티니핑 캐릭터인지 확인할 수 있습니다

// Character type 정의
type Character<K, T> = K & { _Character: T };

// 티니핑 타입 정의
type 티니핑 = Character<string, '티니핑'>;

// 마지막 글자가 '핑'으로 끝나는지 체크하는 함수
function is티니핑(name: string): name is 티니핑 {
  return name.endsWith('핑');
}

// 티니핑 캐릭터만 허용하는 함수
//매개변수 character타입 외 제한
function introduceCharacter(character: 티니핑) {
  console.log(`안녕하세요, 저는 ${character}입니다!`);
}

// 일반 문자열과 티니핑 문자열 예시
const Character1 = "구조적타이핑";
const Character2 = "하츄핑" as const;

// 타입 검사
if (is티니핑(tinipingCharacter)) {
  introduceCharacter(tinipingCharacter); // OK
} else {
  console.log(`${tinipingCharacter}는 티니핑이 아닙니다.`);
}

if (is티니핑(normalCharacter)) {
  introduceCharacter(normalCharacter); // 타입 오류 발생, normalCharacter는 티니핑이 아님
} else {
  console.log(`${normalCharacter}는 티니핑이 아닙니다.`);
}

//result 
안녕하세요, 저는 하츄핑입니다!
구조적타이핑는 티니핑이 아닙니다.

3. Index Signature를 이용한 타입 호환성

객체가 고정된 속성 외에도 임의의 속성을 가질 수 있음을 타입스크립트에게 알려주는 방법

🤔 티니핑의 종류에 대해서 알아보자면..

티니핑에서 가장 우수한 티니핑으로 로열 티니핑 6종이 있다고 합니다

뿐만 아니라 레전드 티니핑 , 일반 티니핑, 빌런 티니핑 등 여러 종류가 있습니다 !

https://namu.wiki/w/티니핑#s-3.4

해당 속성을 옵션 속성을 통해 추가로 알려줄 수 있습니다

그럼 다음과 같이 기본 타입을 확장할 수 있습니다

// 기본 티니핑 타입 정의
interface 티니핑 {
  name: string;
  strength: number;
  agility: number;
  intelligence: number;
  [key: string]: number | string | boolean | undefined; // 추가적인 속성 허용
  type: string;  // 티니핑 종류 (일반, 레전드, 빌런 등)
}

// 레전드 티니핑 타입 정의 (티니핑을 확장)
interface 레전드티니핑 extends 티니핑 {
  legendaryPower: string;  // 레전드 티니핑만의 특별한 능력
}

// 빌런 티니핑 타입 정의 (티니핑을 확장)
interface 빌런티니핑 extends 티니핑 {
  evilPower: string;   // 빌런 티니핑만의 특별한 능력
  invertedTrianglePattern: boolean; 
  // 빌런 티니핑은 뿌뿌핑, 트러핑을 제외하면 눈밑에 역삼각형 무늬가 있음
}

// 일반 티니핑 타입 정의 (특별한 속성 없이 기본 티니핑 속성만 가짐)
type 일반티니핑 = 티니핑;

// 일반 티니핑 객체
const 일반TiniPing: 일반티니핑 = {
  name: "키키핑",
  strength: 30,
  agility: 35,
  intelligence: 40,
  type: "일반",
};

// 레전드 티니핑 객체
const 레전드TiniPing: 레전드티니핑 = {
  name: "행운핑",
  strength: 80,
  agility: 70,
  intelligence: 90,
  type: "레전드",
  legendaryPower: "행운전달🍀", // 레전드 티니핑만의 특별한 능력
};

// 빌런 티니핑 객체
const 빌런TiniPing: 빌런티니핑 = {
  name: "악동핑",
  strength: 60,
  agility: 55,
  intelligence: 65,
  type: "빌런",
  evilPower: "번개발사⚡️", // 빌런 티니핑만의 특별한 능력
  invertedTrianglePattern: true, // 역삼각형 무늬 여부
};

// 티니핑의 능력치를 계산하는 함수
function calculatePower(tiniPing: 티니핑): number {
  return tiniPing.strength * 2 + tiniPing.agility * 1.5 + tiniPing.intelligence * 3;
}

// 티니핑을 소개하는 함수
function introduceTiniPing(tiniPing: 티니핑) {
  console.log(`안녕하세요, 저는 ${tiniPing.name}입니다. 저는 ${tiniPing.type} 티니핑이에요!`);

  if ('legendaryPower' in tiniPing) {
    console.log(`저의 전설적인 능력은 ${tiniPing.legendaryPower}입니다!`);
  }

  if ('evilPower' in tiniPing) {
    console.log(`저의 악당 능력은 ${tiniPing.evilPower}입니다!`);
    if ((tiniPing as 빌런티니핑).invertedTrianglePattern) {
      console.log("저는 역삼각형 무늬를 가진 빌런 티니핑입니다!");
    }
  }

  console.log(`능력치 합계: ${calculatePower(tiniPing)}`);
}

// 티니핑 객체 출력
introduceTiniPing(일반TiniPing);   // 일반 티니핑 소개
introduceTiniPing(레전드TiniPing); // 레전드 티니핑 소개
introduceTiniPing(빌런TiniPing);   // 빌런 티니핑 소개

//strength: number; agility: number; intelligence: number;는 임의로 지정한 것 입니다 ! 

정리 🧹

📚 핑으로만 끝난다고 혹은 모든 티니핑이 일반 티니핑은 아니듯이 타입 구분의 필요성을 느꼈습니다!!

퀴즈 1: 구조적 서브타이핑

다음 코드에서 calculateLength 함수에 NamedVector 타입의 객체를 전달할 수 있는 이유는 무엇일까요?

interface Vector2D {
  x: number;
  y: number;
}

function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y);
}

interface NamedVector {
  name: string;
  x: number;
  y: number;
}

const v: NamedVector = { name: "zee", x: 3, y: 4 };
console.log(calculateLength(v)); // 결과: 5

• 정답

  Vector2D와 NamedVector는 명시적으로 상속 관계에 있고

  NamedVector는 Vector2D에서 요구하는 모든 속성(x, y)을 가지고 있기 때문

  TypeScript는 항상 모든 객체를 호환 가능하게 처리하기 때문

  NamedVector의 구조가 더 복잡하므로 자동으로 호환됨

퀴즈 2: 명목적 서브타이핑

다음 언어 중 명목적 서브타이핑(Nominal Subtyping)을 사용하는 언어는 무엇일까요?

1. TypeScript
2. JavaScript
3. Java
4. Python

• 정답
  1. Java는 명목적 서브타이핑을 사용하는 언어로, 상속 관계가 명확히 명시된 경우에만 타입 호환을 허용합니다

퀴즈 3: 브랜딩된 타입

다음 코드를 실행할 때 타입 오류가 발생하는 이유는 무엇일까요?

type Brand<K, T> = K & { __brand: T };

type Food = Brand<{
  protein: number;
  carbohydrates: number;
  fat: number;
}, 'Food'>;

function calcCalory(food: Food) {
  return food.protein * 4 + food.carbohydrates * 4 + food.fat * 9;
}

const burger = {
  protein: 100,
  carbohydrates: 100,
  fat: 100,
  burgerBrand: '버거킹'
};

calcCalory(burger); // 오류 발생

• 정답

  Food 타입과 burger 타입이 구조적으로 일치하지 않기 때문에

  • burger에 __brand: 'Food'가 없기 때문에
  • calcCalory 함수는 매개변수로 burgerBrand를 허용하지 않기 때문에

퀴즈 4: Index Signature

FlexibleFood 인터페이스가 Food와 다른 점은 무엇일까요?

interface Food {
  protein: number;
  carbohydrates: number;
  fat: number;
}

interface FlexibleFood {
  protein: number;
  carbohydrates: number;
  fat: number;
  [key: string]: number | string; // 추가 속성 허용
}

• 정답

  Food는 고정된 속성만 가질 수 있다

  FlexibleFood는 Food와 달리 추가적인 속성을 허용한다

  FlexibleFood는 타입 호환성 문제를 발생시킨다

  FlexibleFood는 Food를 상속한 타입이다