하나 둘 🐌 하나 둘 🐌 (나름 전력질주 중)

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

interface Crew {
  name: SophiaName | SellyName | HopeName;
  emoji: SophiaEmoji | SellyEmoji | HopeEmoji;
}

name이 SophiaName이면서 emoji가 SellyEmoji일 수는 없다. 이런 조합을 허용하면 오류가 발생하기 쉽고 인터페이스를 다루기 어려워진다 → 각각의 타입의 계층을 분리된 인터페이스로 두자

interface SophiaCrew {
  name: SophiaName;
  emoji: SophiaEmoji
}

이런 형태로 정의하면 속성이 잘못된 조합으로 섞이는 경우를 방지할 수 있다.

태그된 유니온 사용하기. type이라는 필드를 추가하여 구분하기. 태그를 추가하여 런타임에 어떤 타입이 사용되는지 판단할 때 사용된다. 이러면 타입스크립트가 코드의 정확성을 체크하는데 도움이 된다.

interface SophiaCrew {
  type: 'sohpia'
  name: SophiaName;
  emoji: SophiaEmoji
}

interface SellyCrew {
  type: 'selly'
  name: SellyName;
  emoji: SellyEmoji
}

interface HopeCrew {
  type: 'hope'
  name: HopeName;
  emoji: HopeEmoji
}

type Crew = SophiaCrew | SellyCrew | HopeCrew;

여러개의 선택적 필드가 동시에 값이 있거나 동시에 undefined인 경우, 두개의 속성을 하나의 객체로 모으는 것이 더 좋은 설계이다.

interface Person {
  name: string;
  // 두 값이 동시에 있거나 없어야 한다
  placeOfBirth?: string;
  dateOfBirth?: Date;
}

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

API의 결과와 같이 타입의 구조를 손 댈 수 없는 상황이면 인터페이스의 유니온을 사용해서 속성 사이의 관계를 모델링하자.

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

string 타입의 범위는 매우 넓다. 변수의 범위를 정확하게 표현하고자 한다면 string 타입보다는 문자열 리터럴의 유니온을 사용하면 된다.

타입을 명시적으로 정의함으로써 다른 곳으로 값이 전달되어도 타입 정보가 유지된다.
타입을 명시적으로 정의하고 해당 타입의 의미를 설명하는 주석을 넣을 수 있다.
keyof 연산자로 세밀하게 객체의 속성 체크가 가능하다.

function pluc(records: any[], key: string): any[] {
  return records.map(r => r[key]);
}

// any가 있어 좋지 않다. generic을 도입해보자

function pluc2<T>(records: T[], key: string): any[] {
  return records.map(r => r[key]);
  // Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'unknown'.
  // No index signature with a parameter of type 'string' was found on type 'unknown'.
}

// key의 타입이 string이라 범위가 너무 넓다
// 객체의 속성 이름을 함수 매개변수로 받을 때는 keyof T를 사용하자
function pluc3<T>( records: T[], key: keyof T){
  return records.map(r => r[key]);
}

// 범위를 더 좁히기 위해서 keyof T의 부분집합을 도입하자
// string 대신 keyof를 사용하면 자동완성 기능도 개선된다
function pluc4<T, K extends keyof T>( records: T[], key: K): T[K][]{
  return records.map(r => r[key]);
}

부정확한 타입보다는 미완성 타입을 사용하기

잘못된 타입은 차라리 타입이 없는 것보다 못할 수 있다.
any와 unknown을 구별해서 사용해야 한다.
타입 정보를 구체적으로 만들수록 오류 메시지와 자동 완성 기능에 주의를 기울여야 한다.

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

외부에서 비롯된 것들은 예시 데이터가 아니라 명세를 참고해서 타입을 생성해야 한다
예시 데이터를 참고해 타입을 생성하면 눈 앞에 있는 데이터들만 고려하게 되어 예기치 않은 곳에서 오류가 발생할 수 있다.

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

가독성을 높이고, 추상화 수준을 올리기 위해서 해당 분야의 용어를 사용해야 한다.
같은 의미에 다른 이름을 붙이면 안된다. 특별한 의미가 있을 때만 용어를 구분해야 한다.

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

타입스크립트는 구조적 타이핑을 사용하기 떼문에 값을 세밀하게 구분하지 못하는 경우가 있다.

nominal typing

이름으로 타입을 구분하는 것. C, C++에서 사용하는 방식

class A {
    method(input: string): number {...}
}
class B {
    method(input: string): number {...}
}

let a: A = new B(); // Error

타입스크립트는 기본적으로 Structural 타입인데 코드를 더하여 normial의 이점을 가져갈 수 있다. _brand( _brand 형식은 컨벤션이다)를 추가하는 것이다. 값을 구부하기 위해 상표를 붙이는 것이라고 생각하면 좋다.

type ValidatedInputString = string & { __brand: "User Input Post Validation"}; // string타입에 상표 붙이기

// 제약 조건을 만족하는 문자열로 변환하는 함수
const validateUserInput = (input: string) => {
    const simpleValidatedInput = input.replace(/\</g, "<=");
    return simpleValidatedInput as ValidatedInputString;
};

// 조건을 만족하는 문자열만 받아 출력하는 함수
const printName = (name: ValidatedInputString) => {
    console.log(name);
}

type Meters = number & {_brand: 'meters'} // number타입에 상표 붙이기
// brand를 붙여도 산술 연산 후에는 없어지기 때문에 사용하기에 문리가 있을 수 있다

참고

https://www.typescriptlang.org/play#example/nominal-typing

드디어 3장 탈출🐌

타입 추론에 문맥이 어떻게 사용되는지 이해하기

type Language = 'Javascript' | 'Typescript' | 'Python';
function setLanguage(language: Language){ } 

setLanguage('Javascript')  // 정상 

let language = 'Javascript';
setLanguage(language); // string 형식의 인수는 'Language'형식의 매개변수에 할당 할  수 없음

값을 변수로 분리해내면서, 타입을 string으로 추론했고 Language 타입에 할당 불가능하므로 에러가 발생하게 된다
- 해결 방법
  - 타입선언에서 language의 가능한 값을 제한하는 것
```
let language: Language = 'Javascript';
```
  - language를 상수로 만드는 것
```
const language = 'Javascript';
setLanguage(language);
```

튜플 사용 시 주의점

function panTo(where: [number, number]){}

panTo([10,20]); // 정상 

const loc = [10,20];
panTo(loc) // 에러 발생! number[] 형식은 [number,number]에 할당 할 수 없다

해결 방법

타입 선언을 제공하는 방법

const loc : [number, number] = [10,20];
panTo(loc); // 정상

상수 문맥을 제공하기 , panTo 함수에 readonly 구문을 추가하는 것

const는 값이 가리키는 참조가 변하지 않는 얕은 상수
as const는 그 값 내부까지 상수라고 판단

const loc = [10, 20] as const;
panTo(loc); // readonly [10,20]의 형식은 readonly이며 
// 변경가능한 [number,number]에 할당 할 수 없다 

fucntion panTo(where: readonly[number,number]) { } 
const loc = [10, 20] as const;
panTo(loc); // 정상

as const의 단점
- 타입 정의에 실수가 있다면, 오류는 타입 정의가 아니라 호출 되는 곳에서 발생한다

객체 사용시 주의점

type Language = 'JavaScript' | 'TypeScript' | 'Python';
interface GovernedLanguage {
    language : Language;
    organization : string;
} 

function complain(language: GovernedLanguage) { } 

const ts = {
    language: 'TypeScirpt',
    organizaiton: 'Microsoft',
}
complain(ts) // language가 string타입으로 추론되어서, 에러가 발생하게 된다

타입 선언을 추가하기 ts : GovernedLanguage
상수 단언 사용하기 as const

콜백 사용시 주의점
- 콜백을 다른 함수로 전달할 때, 타입스크립트는 타입을 문맥을 통해서 추론한다
- 이 때문에, 콜백을 따로 상수로 뽑아 내면 타입이 소실되게 된다 이럴 때에는 매개변수에 타입 구문을 추가하여 해결할 수 있다

함수형 기법과 라이브러리로 타입 흐름 유지하기

서드파티 라이브러리를 기반으로 사용하게 되면, 타입 정보를 참고하여 작업할 수 있어서 이점이 있다.

타입 설계

타입 시스템의 장점은 데이터 타입을 명확히 알 수 있어 코드를 이해하기 쉽다

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

interface State {
    pageText: string;
    isLoading: boolean;
    error ?: string;
} 

function renderPage(state: State){
    if(state.error){
        return `Error`
  } else if (state.isLoading){
        return 'Loading';
    } 
    return `ㄴㄴㄴㄴ`
} -> isLoading이 true이고 error가 존재할 경우에 대해서 로딩 중인 상태인지 에러 상태인지 명확하게 
구분이 불가능하다

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`); -> 오류가 발생했을 때에, isLoading이 false로
            되는 로직 부재 
            -> state.error를 초기화하지 않아 과거의 오류 메세지가 보여질 수 있다 
        }
        const text = await response.text();
        state.isLoading = false;
        state.pageText = text;
    } catch (e) {
        state.error = ' ' | e;
    }
}

-> 페이지 로딩 중에 사용자의 페이지가 바뀌어 버리면, 어떤 일이 발생할지 예상하기 어렵다.

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

interface RequestPending {
    state: 'pending';
}

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

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

type RequestState = RequestPending | RequestError | RequestSuccess;

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

함수의 매개변수는 타입의 범위가 넓어도 된다
함수의 결과를 반환할 때에는 타입의 범위가 구체적이여야 한다
매개변수와 반환 타입의 재사용을 위해서 기본 형태와 느슨한 형태를 도입하는 것이 좋다

부정확한 타입보다는 미완성의 타입 사용하기

타입이 없는 것 보다 부정확한게 더 나쁘다.
정확하게 타입을 모델링 할 수 없다면, 부정확하게도 모델링하지말자.

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

예시 데이터를 참고해 타입을 생성하면 눈앞에 있는 데이터들만 고려하게 되므로 예기치 않은 곳에서 오류가 발생 할 수 있다.
데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있으므로, 데이터보다는 명세로부터 코드를 생성하자.

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

자체적으로 용어를 만들어 내려고 하지 말고, 해당 분야에 이미 존재하는 용어를 사용하자.
동일한 의미를 나타낼 때는 같은 용어를 사용하자.
data, info, thing, item, object, entity 와 같은 모호하고 의미 없는 이름은 피하자.
이름을 지을 때는 포함된 내용이나, 계산 방식이 아니라 데이터 자체가 무엇인지 고려하자. INodeList 보다 Directory 가 더 의미있는 이름이다.
- 왜? Directory 는 구현의 측면이 아니라 개념적인 측면에서 디렉터리를 생각하게 한다.
- 좋은 이름은 추상화의 수준을 높이고, 의도치 않은 충돌의 위험성을 낮춘다.

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

구조적 타이핑의 특성 때문에 코드가 이상한 결과를 낼 수 있다.

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

function calculateNorm(p:Vector2D){}

const vec3D = {x: 3, y:4, z:1};
calculateNorm(vec3D); // 정상!!

수학적으로는 2차원 벡터를 사용해야 이치에 맞는다.
calculateNorm 함수가 3차원 벡터를 허용하지 않게 하려면 공식 명칭(Nominal typing) 을 사용하자
공식 명칭을 사용한다는 것은, 타입이 아니라 값의 관점에서 Vector2D 라고 말하는 것!

interface Vector2D{
  _brand:'2D';
  x: number;
  y: number;
}

function calculateNorm(p:Vector2D){}

const vec3D = {x: 3, y:4, z:1};
calculateNorm(vec3D); // _brand 속성이 형식에 없습니다.

브랜딩 기법은 타입 시스템에서 동작하지만, 런타임에 브랜드를 검사하는 것과 동일한 효과를 얻을 수 있다.
타입시스템이기 때문에 런타임 오버헤드를 줄일 수 있고, 추가속성을 붙일 수 없는 string 이나 number와 같은 내장 타입도 상표화할수 있다.

type AbsoultePath = string & {_brand:'abs'};

function listAbsolutePath(path: AbsoultePath){
  // ..
}

function isAbsolutePath(path:string): path is AbsoultePath{
   return path.startsWith('/');
}

function f(path:string){
    if(isAbsolutePath(path)){
        listAbsolutePath(path);
    }
    listAbsolutePath(path); // error 
}

이런 식으로 상표(brand)를 붙여서, 타입이 특정한 성격을 가졌는지 구분할 수 있다.
이는, 런타임에 if 문으로 체크하는 것과 같은 효과를 내지만, 런타임이 아니라 타입시스템으로 작동하기 때문에 런타임 오버헤드가 없다!

any 타입은 가능한 한 좁은 범위에서만 사용하기


type Bar = 'example';
function processBar(b:Bar){}

function f1(){
    const x: any = 'foo';
    processBar(x); // 이렇게 하지마시오
}

function f2(){
    const x= 'foo';
    processBar(x as any); // 이게 낫다.
}

왜 2번이 낫는가..?
2번에서 any 타입은 processBar 함수의 매개변수에서만 사용된 표현식이므로 다른 코드에 영향을 미치지 않기 때문이다.
즉, f1 에서 함수의 마지막까지 x 의 타입이 any 인 반면, f2 에서는 processBar 호출 이후 x 가 다시 원래 타입으로 돌아간다.
또한 f1 에서 설상가상 x 를 리턴한다면..?! -> 해당 함수를 사용하는 모든 곳에서 any 타입이 전염병처럼 퍼진다.
비슷한 관점에서 타입스크립트가 함수의 반환 타입을 추론 할 수 있는 경우에도 함수의 반환 타입을 명시해야 한다. 함수의 반환 타입을 명시하여 any 타입이 함수 바깥으로 영향을 미치는 것을 방지 할 수 있기 때문이다.

침착해. 네가 가야할 곳에만 집중해야 해. 🐌🐌🐌

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

값이 전부 null이거나 전부 null이 아닌 경우로 분명히 구분하면, 값이 섞여 있을 때보다 다루기 쉽다. 타입에 null을 추가하는 방식으로 두 경우를 구분하는 모델링을 할 수 있다.
한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안 된다.
strickNullChecks를 설정하면 null 값과 관련된 문제점을 찾을 수 있으므로 반드시 필요하다.
API 작성 시 반환 타입을 큰 객체로 만들어 반환 타입 전체가 null이거나 null이 아니게 만들어야 한다.

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

유니온 타입의 속성을 가지는 인터페이스를 작성 중이라면, 인터페이스의 유니온 타입을 사용하는 게 더 적절하지 않은지 검토해본다. 유니온 타입의 속성을 여러 개 가지는 경우, 속성 간의 관계가 분명하지 않아 실수가 자주 발생한다. 인터페이스의 유니온으로 표현하는 방식이 더 정확하고 타입스크립트가 이해하기 좋다.

태그된 유니온은 타입스크립트와 잘 맞다. 어떤 데이터 타입을 태그된 유니온으로 표현할 수 있다면 보통은 그렇게 하는 것이 좋다. 여러 개의 선택적 필드가 동시에 값이 있거나 없는(undefined)인 경우도 태그된 유니온 패턴이 잘 맞다.

interface Layer {
    layout: FillLayout | LineLayout | PointLayout;
    paint: FillPaint | LinePaint | PointPaint;
}

// 위 인터페이스는 LineLayout과 FillPaint와 같은 조합을 허용한다.
// 이와 같은 조합을 허용하면 오류가 발생하기 쉬우므로 인터페이스를 분리한다.

// type 속성을 '태그'로 추가하여 런타임에 어떤 타입이 사용되는지 판단하는데 사용하자.
// 타입스크립트는 태그를 참고하여 타입의 범위를 좁힌다.

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;

두 속성이 동시에 있거나 없는 경우 두 개의 속성을 하나의 객체로 모으는 설계가 더 낫다.

interface Person {
    name: string;
    placeOfBirth?: string;
    dateOfBirth?: Date;
}

// placeOfBirth와 dateOfBirth는 함께 있거나 함께 없다.
// 두 필드는 서로 관련되어 있지만 타입 정보에서는 관련성이 드러나지 않는다.
// 두 속성을 하나의 객체로 모아 타입 정보에 관계를 표현한다.
interface Person {
    name: string;
    birth?: {
        place: string;
        date: Date;
    }
}
// 위와 같이 작성하면
// 1. place 없이 date만 있는 경우에 오류가 발생한다.
// 2. Person 타입의 객체를 사용할 때 birth의 존재 여부만 체크하면 된다.

API 응답 결과의 경우 타입의 구조에 손 댈 수 없다. 이 경우 인터페이스의 유니온을 사용하여 속성 사이의 관계를 모델링할 수 있다.

interface Name {
    name: string;
}

interface PersonWithBirth extends Name {
    placeOfBirth: string;
    dateOfBirth: Date;
}

type Person = Name | PersonWithBirth;

function eulogize(p: Person) {
    if ('placeOfBirth' in p) {
        // 타입이 PersonWithBirth
    }
}

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

string 타입보다 더 구체적인 타입을 사용하면 타입스크립트는 오류를 더 잘 체크할 수 있다.

구체적인 타입 사용의 예시
- 날짜 형식의 필드라면? ⇒ string 타입보다는 Date 객체를 사용하여 날짜 형식으로 제한
- 값의 수가 정해진 필드라면? ⇒ 유니온 타입으로 정의
- 객체의 속성 이름을 매개변수로 받는다면? ⇒ keyof T를 사용
```
type RecordingType = 'studio' | 'live';

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

구체적인 타입 사용의 장점

타입을 명시적으로 정의하면 값이 다른 곳으로 전달 되어도 타입 정보가 유지된다.
타입을 명시적으로 정의하면 해당 타입의 의미를 설명하는 주석을 넣을 수 있다. 명명된 타입을 사용하면 주석으로 타입에 설명을 붙일 수 있고, 편집기에서 설명을 확인할 수 있다.
keyof 연산자로 더욱 세밀한 객체 속성 체크가 가능해진다.

keyof의 매개변수 타입을 사용하면 편집기의 자동 완성 기능도 개선된다.

// 배열 요소에서 한 필드의 값을 추출하는 함수를 작성해보자.

function pluck<T>(records: T[], key: keyof T) {
    return records.map(record => record[key]);
}
// 함수의 타입은 function pluck<T>(records: T[], key: keyof T): T[keyof T][]

const albums: Album[] = [];
const releaseDates = pluck(albums, 'releaseDate');
// releaseDates의 타입은 (string | Date)[]
// T[keyof T][]의 범위는 넓다. 범위를 좁혀주자!

// 두 번째 제너릭 매개변수로 keyof T의 부분 집합인 K를 도입한다.
function pluck<T, K extends keyof T>(records: T[], key: K): T[K][] {
    return records.map(record => record[key]);
}

아이템 34. 부정확한 타입보다는 미완성 타입을 사용하기

실수가 발생하기 쉽고 잘못된 타입은 없는 것보다 못하다.
난해한 오류 메시지를 만들거나 언어 서비스 경험을 떨어트리는 타입을 만들지 않도록 주의한다. 이는 타입스크립트 개발 경험을 해친다.
any와 unknown을 구별해서 사용한다. any는 타입을 좁히지 않아도 되지만, unknown은 타입을 먼저 확인한 후에 사용할 수 있어 any보다 안전하다.

[Documentation - TypeScript 3.0](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type)

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

예시 데이터를 참고해 타입을 생성하면 보이는 데이터만 고려하게 되므로 예기치 않은 곳에서 오류가 발생할 수 있다. 명세를 참고해 타입을 생성하는 것이 좋다.

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

엄선된 타입, 속성, 변수의 이름은 의도를 명확히 하고 코드와 타입의 추상화 수준을 높여 준다.
코드로 표현하고자 하는 모든 분야에는 주제를 설명하는 전문 용어들이 있다. 이미 존재하는 분야의 용어를 사용해야 한다. 이를 사용하면 사용자 소통에 유리하고 타입의 명확성을 올릴 수 있다. (단, 정확하게 사용해야 한다. 다른 의미로 잘 못 쓰면 오히려 혼란을 주게 된다.)
같은 의미에는 같은 이름을 사용한다.
모호하고 의미 없는 이름은 피해야 한다. (data, info, thing, item, entity…)

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

타입스크립트는 structural typing이라, 값을 세밀하게 구분하지 못하는 경우가 있다. 값을 세밀하게 구분하려면 nominal typing이 필요하다. Nominal typing을 타입스크립트에서 흉내 내려면, 상표(_brand)를 붙이면 된다.

interface Vector2D {
    _brand: '2d';
    x: number;
    y: number;
}

function vec2D(x: number, y: number): Vector2D {
    return {x, y, _brand: '2d'};
}

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

calculateNorm(vec2D(3, 4)); // 정상, 5 반환

const vec3D = {x: 3, y: 4, z: 1};
calculateNorm(vec3D); // 오류! '_brand' 속성이 ... 형식에 없습니다.

상표 기법은 타입 시스템에서 동작하지면 런타임에 검사하는 것과 동일한 효과를 얻을 수 있다. 타입 시스템이기 때문에 런타임 오버헤드를 없앨 수 있고, 추가 속성을 붙일 수 없는 내장 타입(string이나 number 같은)도 상표화할 수 있다.

type AbsolutePath = string & { _brand: 'abs' };
// string 타입이면서 _brand 속성을 가지는 객체를 만들 수는 없다.
// 이는 타입 시스템이기 때문에 가능하다!

function listAbsolutePath(path: AbsolutePath) { /* */ };

function isAbolustePath(path: string): path is AbsolutePath {
    return path.startsWith('/');
}

function f(path: string) {
    if (isAbolustePath(path)) {
        // path의 타입은 AbsolutePath
        listAbsolutePath(path);
    }
    // path의 타입은 string
    listAbsolutePath(path); 
    // 오류! string 형식은 AbsolutePath 형식의 매개변수에 할당될 수 없다.
}

// number 타입에도 상표를 붙일 수 있다.
type Meters = number & { _brand: 'meters' };

const meters = (m: number) => m as Meters;

const oneKm = meters(1000); // 타입 Meters
const tenKm = 10 * oneKm; // 타입 number
// 단, 산술 연산 후에는 상표가 없어진다.

woowacourse-study / 2022-thanks-giving-effective-typescript

2022.09.11 #8

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

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

부정확한 타입보다는 미완성 타입을 사용하기

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

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

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

nominal typing

참고

타입 추론에 문맥이 어떻게 사용되는지 이해하기

함수형 기법과 라이브러리로 타입 흐름 유지하기

타입 설계

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

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

부정확한 타입보다는 미완성의 타입 사용하기

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

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

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

any 타입은 가능한 한 좁은 범위에서만 사용하기

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

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

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

아이템 34. 부정확한 타입보다는 미완성 타입을 사용하기

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

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

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