타입설계 - 이펙티브 타입스크립트

28. 유효한 상태만 표현하는 타입을 지향하기

네트워크 요청 과정 각각의 상태를 명시적으로 모델링하는 태그된 유니온을 사용하는 것이 좋다. 

-> 유효한 상태와 무효한 상태를 둘 다 표한하는 타입을 사용한 적이 있는 반성..
ex. 

interface RequestPending {
  state: 'pending';
}

interface RequestError {
  state: 'error';
  error: string;
}

interface RequestPending {
  state: 'ok';
  pageText: string;
}

type RequestState = RequestPending | RequestError | RequestSuccess;

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

 

29. 사용할 때는 너그럽게, 생성할 때는 엄격하게 

매개 변수 타입은 범위가 넓으면 사용하기 편하고, 반환 타입의 범위는 넓으면 불편하다. 

ex. 

사용하기 편리한 API일수록 반환 타입이 엄격하다. 

 

30. 분서에 타입 정보를 쓰지 않기 

코드와 주석이 맞지 않는다면, 둘 다 잘못된 것이다!

누군가 강제하지 않는 이상 주석은 코드와 동기화되지 않습니다. 주석 대신 타입 정보를 작성하다면 코드가 변경된다 하더라도 정보가 정확히 동기화됩니다. 

 

• 매개 변수 설명 : JSDoc @param
• 매개변수 변경하지 않을 때: readonly
• 변수명에 타입을 넣지 않고 타입지정
• 단위가 있다면 변수명에 들어가도 좋다. 

31. 타입 주변에 null 값 배치하기

• 반환 타입을 큰 객체로 만들고, 반환 타입 전체가 null 이거나 null 이 아니도록 만들기
• 클래스 생성시에는 필요한 모든 값이 준비되었을 떄 생성하여 null 존재 가능성을 없애기
• strictNullChecks 를 설정하면 코드에 많은 오류가 표시되겠지만, null 값과 관련된 문제점을 찾아낼 수 있기 때문에 반드시 필요하다. 

 

32. 유니온의 인터페이스보다는 인터페이스의 유니온 사용하기

인터페이스의 유니온 사용하기 & 타입에 태그 넣기

bad ex.

interface Layer {
  type: 'fill' | 'line' | 'point';
  layout: FillLayout | LineLayout | PointLayout;
  paint: FillPaint | LinePaint | PointPaint;
}

 

best ex. 

interface FillLayer {
  type: 'fill';
  layout: FillLayout;
  paint: FillPaint;
}
interface LineLayer {
  type: 'line';
  layout: LineLayout;
  paint: LinePaint;
}
interface PointLayer {
  type: 'paint';
  layout: PointLayout;
  paint: PointPaint;
}
type Layer = FillLayer | LineLayer | PointLayer;

 

두 개의 속성을 하나의 객체로 모으기

bad ex.

interface Person {
  name: string;
  // These will either both be present or not be present
  placeOfBirth?: string;
  dateOfBirth?: Date;
}

good ex.

interface Person {
  name: string;
  birth?: {
    place: string;
    date: Date;
  }
}

33. string 타입보다 더 구체적인 타입 사용하기

bad ex.string이 남용된 코드 = stringly typed

-> 난가.. 싶어서 반성

interface Album {
  artist: string;
  title: string;
  releaseDate: string;  // YYYY-MM-DD
  recordingType: string;  // E.g., "live" or "studio"
}

good ex.

type RecordingType = 'studio' | 'live';

interface Album {
  artist: string;
  title: string;
  releaseDate: Date;
  recordingType: RecordingType;
}

객체의 속성 이름을 함수 매개변수로 받을 때는 string 보다 keyof T 를 사용하자. 

34. 부정확한 타입봐는 미완성 타입을 사용하기 

• 타입이 없는 것보다 잘못된 것이 더 나쁘다. 
• 정확하게 타입을 모델링할 수 없다면 부정확하게 모델링하지 말 것.
• any 와 anknown을 구별해서 사용하기 

35. 데이터가 아닌 API와 명세를 보고 타입 만들기

• 스웨거 등의 명세를 보고 타입 만들기. 
• api 에서 약속된 타입이 내려오지 않을때, null escaping 처리 또는 유니온 처리가 아니라 서버 개발자에게 Api 수정 요청! 

36. 해당 분야의 용어로 타입 이름 짓기

• 도메인 지식이 조금 필요하지 않을까 정도의 생각이다.
• 정보를 찾기 위해 사람에 의존하지 않도록 네이밍 짓기
• 같은 의미에 다른 이름을 붙이면 안 됩니다. -> response 의 snake case를 camel case 로 변환하여야 할까?

37. 공식 명칭에는 상표를 붙이기

-

 

참고: 이펙티브 타입스크립트

http://www.yes24.com/Product/Goods/102124327

이펙티브 타입스크립트 - YES24