DIL: 이펙티브 타입스크립트

스터디: 월간 CS, https://github.com/monthly-cs/2024-05-effective-typescript
작성일: 2024-05-27
작성자: dusunax

---

4장 타입 설계

타입과 로직

• 프레드 브룩스
  • 코드의 타입: 테이블
  • 코드의 로직: 순서도
• 타입과 로직
  • 연산이 이루어지는 데이터나 데이터 타입을 알 수 없다면 코드를 이해할 수 없다
  • 데이터 타입을 명확하게 해, 코드를 이해하기 쉽게 한다

아이템 28: 유효한 상태만 표현하는 타입을 지향하기 Prefer Types That Always Represent Valid States

• 유효한 상태만 표현할 수 있는 타입을 만드는 것이 중요하다
  • 유효하지 않은 타입이 존재하는 경우 => 타입 설계가 잘못된 경우

문제 코드 예시

async function changePage(state: State, newPage: string) {
  state.isLoading = true;
  try {
    const response = await fetch(getUrlForPage(newPage));
    if (!response.ok) {
      throw new Error(`Unable to load ${newPage}: ${response.statusText}`);
    }
    const text = await response.text();
    state.isLoading = false;
    state.pageText = text;
  } catch (e) {
    state.error = "" + e;
    // isLoading을 false로 바꾸는 로직이 빠져있음
    // 실행 시, 에러 초기화가 없음
  }
}

| 경우 | 예제 | | ------------------------------------------- | -------------------------------------------------- | | 상태 값의 두 가지 속성이 동시에 정보가 부족 | 요청이 실패한 것인지 여전히 로딩 중인지 알 수 없다 | | 두 가지 속성이 충돌 | 오류이거나, 로딩 중일 수 있다 |

상태를 명시적으로 모델링하는 태그된 유니온 사용

interface RequestPending {
  state: "pending";
}
interface RequestError {
  state: "error";
  error: string;
}
interface RequestSuccess {
  state: "ok";
  pageText: string;
}
type RequestState = RequestPending | RequestError | RequestSuccess;

interface State {
  currentPage: string;
  requests: { [page: string]: RequestState };
}

• 상태의 모호함

// renderPage내 상태 구분 개선
function renderPage(state: State) {
  const { currentPage } = state;
  const requestState = state.requests[currentPage];
  switch (requestState.state) {
    case "pending":
      return `Loading ${currentPage}...`;
    case "error":
      return `Error! Unable to load ${currentPage}: ${requestState.error}`;
    case "ok":
      return `<h1>${currentPage}</h1>\n${requestState.pageText}`;
  }
}

async function changePage(state: State, newPage: string) {
  state.requests[newPage] = { state: "pending" };
  state.currentPage = newPage;
  try {
    const response = await fetch(getUrlForPage(newPage));
    if (!response.ok) {
      throw new Error(`Unable to load ${newPage}: ${response.statusText}`);
    }
    const pageText = await response.text();
    state.requests[newPage] = { state: "ok", pageText };
  } catch (e) {
    state.requests[newPage] = { state: "error", error: "" + e };
  }
}

• 예시: 전자 조종식 항공기의 기장 vs 부기장 스틱 State
  • 전자 조종식 스틱의 경우, 스틱의 각도를 평균내는 함수를 사용했다
  • 기계적으로 연결되있다면? 상태 표현은 angle만 존재하면 됨
• 결론: 코드의 로직을 분명하게 하자
  • 타입을 설계할 때, 어떤 값을 포함하고 어떤 값을 제외할 지 신중하게 생각하기
  • 유효한 상태 vaid state를 표현하는 값만 허용하기

Things to Remember

• Types that represent both valid and invalid states are likely to lead to confusing and error-prone code.
  • 유효한 값 & 유효하지 않은 값을 함께 나타내는 상태값은 혼란과 에러를 만든다.
• Prefer types that only represent valid states. Even if they are longer or harder to express, they will save you time and pain in the end!
  • 코드가 더 길거나 어려워지더라도, 유효한 값만을 나타내는 코드를 작성한다.

아이템 29 사용할 때는 너그럽게, 생성할 때는 엄격하게 Be Liberal in What You Accept and Strict in What You Produce

• 견고성 원칙 robustness principle / 포스텔의 법칙 Postel's Law
  • be conservative in what you do, be liberal in what you accept from others
  • TCP, 존 포스텔 Jon Postel
• 함수 호출을 쉽게 하기
  • ex) 옵셔널 매개변수
  • 내부 로직은? 유니온 타입의 요소별 코드 분기
• 사용하기 편리한 api => 반환 타입이 엄격!

자바스크립트 관례 *-like

• ex) array, array-like

interface LngLat {
  lng: number;
  lat: number;
}
type LngLatLike = LngLat | { lon: number; lat: number } | [number, number];

interface Camera {
  center: LngLat;
  zoom: number;
  bearing: number;
  pitch: number;
}
interface CameraOptions extends Omit<Partial<Camera>, "center"> {
  center?: LngLatLike; // center를 LngLatLike로 변경한 Option 속성
}
type LngLatBounds =
  | { northeast: LngLatLike; southwest: LngLatLike }
  | [LngLatLike, LngLatLike]
  | [number, number, number, number];
// 좋은 설계가 아님
// 하지만 다양한 타입을 허용해야하는 라이브러리일 수 있다

declare function setCamera(camera: CameraOptions): void;
declare function viewportForBounds(bounds: LngLatBounds): Camera;

• 매개변수에는 느슨한 타입 + 리턴 타입에는 정규형 타입

function createUser(data: PartialUser): User {
  return {
    id: generateUniqueId(),
    name: data.name || "Unknown",
    email: data.email || "unknown@example.com",
    age: data.age || 0,
  };
}

function updateUser(id: string, data: PartialUser): User {
  const existingUser = getUserById(id);

  if (!existingUser) {
    throw new Error("User not found");
  }

  return {
    ...existingUser,
    ...data,
  };
}

const newUser = createUser({ name: "Alice" });
console.log(newUser);

const updatedUser = updateUser("123", { email: "alice@example.com" });
console.log(updatedUser);

Iterable<T> over T[]

• 배열 대신 반복 가능한 객체를 받을 수 있습니다.
  • iterable: Set, Map, String...

function processItems<T>(items: Iterable<T>): void {
  for (const item of items) {
    console.log(item);
  }
}

// 배열
const numberArray: number[] = [1, 2, 3, 4, 5];
processItems(numberArray);

// 집합
const numberSet: Set<number> = new Set([1, 2, 3, 4, 5]);
processItems(numberSet);

// 문자열
const text: string = "hello";
processItems(text);

// 맵 (key-value 쌍의 배열을 반복 가능)
const map: Map<string, number> = new Map([
  ["a", 1],
  ["b", 2],
  ["c", 3],
]);
processItems(map);

Things to Remember

• Input types tend to be broader than output types. Optional properties and union types are more common in parameter types than return types.
  • 대체적으로 Input 타입이 Output 타입보다 넓다. 옵셔널 속성과 유니온 타입은 리턴 타입에는 사용되지 않고 보통 매개변수로 사용된다
• Avoid broad return types since these will be awkward for clients to use.
  • 리턴 타입에 넓은 타입 X
• To reuse types between parameters and return types, introduce a canonical form (for return types) and a looser form (for parameters).
  • 매개변수와 반환 타입의 재사용을 위해서 => 매개변수에는 느슨한 형태 + 반환 타입에는 기본 타입
• Use Iterable instead of T[] if you only need to iterate over your function parameter.
  • iterable한 매개변수를 위해서 T[] 대신 Iterable를 사용할 수 있다.

아이템 30: 문서에 타입 정보 쓰지 않기 Don’t Repeat Type Information in Documentation

• 코드와 주석이 맞지 않으면? 둘 다 틀림
• 타입 구문 시스템은?
  • 간결하고, 구체적이며, 쉽게 읽을 수 있다.
• 특정 매개변수를 설명하기 위해 JSDocs의 @param 구문을 사용할 수 있음

| 구분 | 동작 | | --------- | --------------------------------------------- | | 주석 | 구현체와의 정합성이 어긋날 수 있다 | | 타입 구문 | 타입 체커가 타입 정보를 동기화하도록 강제한다 |

타입으로 설명하기

// 주석으로 설명하는 경우
/** Sort the strings by numeric value (i.e. "2" < "10"). Does not modify nums. */
function sortNumerically(nums: string[]): string[] {
  return nums.sort((a, b) => Number(a) - Number(b));
}

// 타입으로 설명하는 경우: 규칙을 강제한다
function sortNumerically(nums: readonly string[]): string[] {
  return nums.sort((a, b) => Number(a) - Number(b));
  //          ~~~~  ~  ~ Property 'sort' does not exist on 'readonly string[]'
  // 규칙에 맞지 않게 때문에 에러가 발생한다
}

• 타입 정보를 변수명에 사용하지 않도록 한다. (단위가 있는 경우를 제외)

| 변수명 | 내용 | | ------ | -------------------------------------------------------- | | ageNum | 변수명을 age로 하고 타입이 number임을 명시하는 것이 좋다 | | timeMs | 변수명이 time일 때는 단위에 대한 정보를 알 수 없다 |

Things to Remember

• Avoid repeating type information in comments and variable names. In the best case it is duplicative of type declarations, and in the worst case it will lead to conflicting information.
  • 주석과 타입을 함께 명시하는 경우 => 중복 정보이거나, 정합성이 어긋난 정보일 수 있다
  • 타입 정보에 모순이 발생
• Declare parameters readonly rather than saying that you don't mutate them.
  • readonly의 경우, 주석으로 명시하지 말고 타입으로 강제하도록 하자
• Consider including units in variable names if they aren't clear from the type (e.g., timeMs or temperatureC).
  • 타입이 명확하지 않은 경우 단위를 변수명에 포함하는 것을 고려한다