https://www.youtube.com/watch?v=XrnQgWzsRVQ

고지가 얼마 안남았읍니다 여러분 화이팅

타입스크립트 기능보다는 ECMAScript 기능을 사용하기

enum 열거형을 쓰면 안되는 이유

숫자 열겨형에 0,1,2 외에 다른 숫자가 할당되면 매우 위험하다.
상수 열거형은 보통 열거형과 달리 런타임에 완전히 제거된다.
enum 열거형은 구조적타이핑이 아니라 명목적 타이핑을 한다. 따라서, 자바스크립트와 타입스크립트에서의 동작이 다르기 때문에 문자열 열겨형은 사용하지 않는 것이 좋다. 열거형 대신 리터럴 타입의 유니온을 사용하자!

매개변수 속성

class Person {
   constructor(public name:string){}
}

매개변수 속성과 일반 속성을 섞어서 사용하면 클래스의 설계가 혼란스러워 진다.

그 외에도..

네임스페이스, 트리플 슬래시 임포트, 데코레이터는 사용하지 말아라.

몽키 패치보다는 안전한 타입을 사용하기

객체에 임의의 속성을 추가하는 것은 side-effect를 야기할 수 있기 때문에 좋지 않다. 또한 타입스크립트까지 더하면 타입 체커는 내장 속성에 대해서는 알고 있지만, 임의로 추한 속성에 대해서는 알지 못한다.

(document as any).monkey = 'Tamarin'

가장 간단하게 해결하는 방법은 any 단언문을 사용하는 것. 하지만 타입 안전성을 상실한다. (as any)

interface Document {
  monkey: string;
}

document.monkey = 'Tamarin';

interface의 기능 중 하나인 보강(augmentation) 사용하기. 타입이 더 안전하고, 주석을 붙일 수 있고, 자동완성을 사용할 수 있으며, 어디를 몽키패치 했는지 기록이 남는다.
- 모듈의 관점에서 이가 제대로 동작하게 하려면 global 선언을 추가해야 한다
- 다만 실행 중에 보강을 적용할 수 없다.

interface MonkeyDocument extends Document {
  monkey: string;
}

(document as MonkeyDocument).monkey = 'Macaque'

구체적인 타입 단언문 사용하기. extends 사용. 몽키 패치된 속성을 참조하는 경우에만 단언문을 사용하거나 새로운 변수를 도입하면 된다.

devDependencies에 typescript와 @types 추가하기

타입스크립트를 시스템 레벨로 설치하면 안된다. 타입스크립트를 프로젝트의 devDependencies에 포함시켜 팀원 모두가 동일한 버전을 사용해야 한다
타입 의존성(@types)을 고려해야 한다. DefinitelyTyped에서 타입 정보를 얻을 수 있다. 이는 devDependencies에 포함시켜야 한다.

타입 선언과 관련된 세 가지 버전 이해하기

@types 의존성과 관련된 세 가지 버전이 있다. 라이브러리 버전, @types 버전, 타입스크립트 버전
라이브러리를 업데이트하는 경우, 해당 @types 역시 업데이트해야 한다.
타입스크립트로 작성된 라이브러리라면 타입 선언을 자체적으로 포함하고, 자바스크립트로 작성된 라이브러리라면 타입 선언을 DefinitelyTyped에 공개하는 것이 좋다.

API 주석에 TSDoc 사용하기

사용자를 위한 문서라면 JSDoc 스타일의 주석을 만드는 것이 좋다. (/** */ 사용하기) 인라인 주석은 편집기가 표시해주지 않는다.

TSDoc에서는 @param과 @returns 같은 규칙을 사용할 수 있다.

TSDoc은 마크다운 형식으로 꾸며진다.

주석에는 타입 정보를 포함하면 안된다

콜백에서 this에 대한 타입 제공하기

this는 정의된 방식이 아니라 호출된 방식에 따라 달라진다.

this 바인딩 과정을 이해하고, 콜백 함수에서 this 를 사용해야 한다면 타입을 명시해주어야 한다.

function addKeyListener{
  el: HTMLElement,
    fn: (this: HTMLElement, e: (KeyboardEvent)=>void )
}

오버로딩 타입보다는 조건부 타입을 사용하기

function double(x: number|string): number | string;

const num = double(12) // string|number
const str = double('x') // string|number

위 선언문에는 number 타입을 매개변수로 넣고 string을 반환하는 경우와 string 타입을 매개변수로 넣고 number를 반환하는 경우가 포함되어 있다.

function double<T extends number|string>(x: T): T;
function double(x: any){ return x + x; }

const num = double(12) // 타입이 12
const str = double('x') // 타입이 'x', 'xx'도 아니고 'x'가 나온다

제너릭으로 모델링 할 수 있지만 너무 과하게 구체적이어진다.

function double(x: number): number;
function double(x: string): string;
function double(x: any) { return x + x; }

function f(x: string|number) {
  return double(x); // 'string'|'number' 형식의 인수는 'string' 형식의 매개변수에 할당될 수 없습니다.
}

여러 가지 타입 선언으로 분리하기.타입 스크립트에서 함수의 구현체는 하나지만, 타입 선언은 몇 개든지 만들 수 있다.

하지만 유니온 타입 관련해서는 문제가 발생한다.

function double<T extends number|string> (
    x: T
): T extends string ? string : number;

function double(x: any) { return x + x; }

function f(x: string|number) {
  return double(x); 
}
// (number|string) extends string ? string : number
// -> (number extends string ? string : number) | (string extends string ? string : number)
// number | string

조건부 타입 이용하기. 반환 타입이 더 정교하다.

의존성 분리를 위해 미러 타입 사용하기

필수가 아닌 의존성을 분리할 때는 구조적 타이핑을 사용하면 된다
공개한 라이브러리를 사용하는 자바스크립트 사용자가 @types 의존성을 가지지 않도록 해야한다.

테스팅 타입의 함정에 주의하기

함수의 실행뿐만 아니라 반환 타입까지 체크하는 테스트 코드를 작성해야 한다.

마지막 4가지 정도는 정리하기 애매해서 키워드만 작성했습니다!

문서에 타입 정보를 쓰지 않기

주석과 변수명에 타입 정보를 적는 것을 피하기
타입이 명확하지 않는 경우는 변수명에 단위 정보를 포함하기

타입 주변에 null 값 배치하기

undefined 보다는 null로 다루기
min, max가 동시에 둘다 undefined이거나 둘 다 undfined가 아닐 수 있다.

function extent(nums: number[]){
    let min, max;
    for (const num of nums) {
        if(!min){
            min = num;
            max = num;
        } else {
            min = Math.min(min, num);
            max = Math.max(max, num); -> max는 이곳에서 number | undefined 가 될 수 있다
        }
    }
    return [min,max];
}

이런 경우에 대하여서는 null 값으로 처리하는 것이 더 편리하다
- min, max를 한 객체에 넣고 null 이거나 아니거나를 확인한다 + null 아님 단언을 활용하면 min, max를 얻을 수 있다
```
let result : [number, number] | null = null;
for (const num of nums){
    if(!result){
        result = [num, num];
    } else{
        result = [Math.min(num, result[0]), Math.max(num, result[1]));
}
```
- 단순 if 문으로 null 인 경우에 대해서 처리해줄 수 있다
한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안된다
API 반환 타입을 큰 객체로 만ㄷ르고 반환 타입 전체가 null | !null 이 아니어야 한다
클래스를 만들 때에는 필요한 모든 값이 준비 되었을 때에 생성하여, null 이 존재하지 않도록 하기
strictNullChecks 설정을 키고 하기

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

제어 흐름 파악을 위해서 태그를 활용하자

태그를 활용하면, 런타임에 어떤 타입의 Layer가 사용되는 판단하는데 쓰일 수 있다

interface FillLayer {
    type: 'fill';
    layout: FillLayout;
}

interface LineLayer {
    type: 'line';
    layout: LineLayout;
}

interface PointLayer {
    type:'paint';
    layout: PointLayout;
}

관계가 있는 타입끼리는 하나로 묶자

두 개의 속성을 하나의 객체로 모아서 null 값 여부로 유효성을 확인한다

interface Person{
    name: string;
    birth? :{ -> birth로 묶인 상태들을 동시 undefined일 경우가 있다 
        place: string;
        date: Date;
    }
}

인터페이스의 유니온을 사용하여 속성 사이의 관계를 모델링하기

interface Name{
    name: string;
}

interface PersonWithBirth {
    placeofBirth: string;
    dateofBirth :Date;
}

type Person = Name: PersonWithBirth;

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

string 타입은 범위가 넓기 때문에, 타입의 범위를 좁히는 방법을 사용해야한다
문자열 리터럴 타입의 유니온을 사용하자

type RecordingType = 'studio' | 'live';

장점
- 타입을 명시적으로 정의함으로써 다른 곳으로 값이 전달되어도 타입 정보가 유지된다
- 타입을 명시적으로 정의하고 해당 타입의 의미를 설명하는 주석을 붙여 넣을 수 있다
- keyof 연산자로 더욱 세밀하게 객체의 속성 체크가 가능해진다
```
function pluck(records: any[], key:string) : any [] {
-> 
type K = keyof Album;
function pluck<T>(records: T[], key: keyof T) {
```
객체의 속성 이름을 함수 매개변수로 받을 때는 string 보다 keyof T를 사용할 것
```
function pluck<T>(records: T[], key: keyof T): T[keyof T][]

const releasDates = pluck(albums, 'releaseData'); 
```
- T[keyof T]는 T 객체 내의 가능한 모든 값의 타입

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

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

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

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

아이템 45. devDependencies에 typescript와 `@types` 추가하기

npm은 자바스크립트 라이브러리 저장소(npm 레지스트리)와 프로젝트가 의존하고 있는 라이브러리들의 버전을 지정하는 방법(package.json)을 제공한다.
- dependencies - 프로젝트 실행에 필수적인 라이브러리들
- devDependencies - 프로젝트 개발, 테스트에 사용되지만 런타임에는 필요 없는 라이브러리들
- peerDependencies - 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리들
타입스크립트는 개발 도구일 뿐 타입 정보는 런타임에 존재하지 않으므로 타입스크립트와 관련된 라이브러리는 일반적으로 devDependencies에 속한다.
타입스크립트의 자체 의존성과 타입 의존성(@types)을 고려한다.
- 시스템 레벨로 설치하면 팀원들의 버전이 달라질 수 있고, 프로젝트 셋업에 별도의 단계가 추가된다. 그러므로 시스템 레벨보다는 devDependencies에 넣는 게 좋다.
- 라이브러리에 타입 선언이 포함되어 있지 않아도 DefinitelyTyped(타입스크립트 커뮤니티에서 유지보수하고 있는 자바스크립트 라이브러리의 타입을 정의한 모음)에서 타입 정보를 얻을 수 있다. DefinitelyTyped의 타입 정의는 @types 스코프에 공개되며 타입 정보만 포함하고 구현체는 포함하지 않는다.
  
  원본 라이브러리는 dependencies에 있더라도 @types 의존성은 devDependencies에 있어야 한다.

아이템 46. 타입 선언과 관련된 세 가지 버전 이해하기

타입스크립트를 사용하면 다음 세 가지 사항을 추가로 고려해야 한다.
- 라이브러리의 버전
- 타입 선언(@types)의 버전
- 타입스크립트의 버전
라이브러리를 업데이트하는 경우, 해당 @types 역시 업데이트해야 한다.
타입 선언을 라이브러리에 포함하는 것과 DefinitelyTyped에 공개하는 것 사이의 장단점을 이해해야 한다. 타입스크립로 작성된 라이브러라면 타입 선언을 자체적으로 포함하고, 자바스크립트로 작성된 라이브러리라면 타입 선언을 DefinitelyTyped에 공개하는 것이 좋다.

아이템 47. 공개 API에 등장하는 모든 타입을 익스포트 하기

라이브러리의 공개 메서드에 등장한 어떤 형태의 타입이든 익스포트 한다. 어차피 추출할 수 있으므로 익스포트하기 쉽게 만드는 것이 좋다.

아이템 48. API 주석에 TSDoc 사용하기

공개 API에 주석을 붙인다면 JSDoc 형태로 작성해야 한다. 여기에는 @param과 @returns 같은 일반적 규칙을 사용할 수 있다. 타입스크립트 언어 서비스가 JSDoc 스타일을 지원하기 때문에, 타입스크립트 관점에서는 TSDoc이라고 부르기도 한다.

아이템 49. 콜백에서 this에 대한 타입 제공하기

let, const는 렉시컬 스코프지만(값이 정의된 방식에 따라 결정) this는 다이나믹 스코프다.(값이 호출된 방식에 따라 결정)
콜백 함수에서 this 값을 사용해야 한다면, 타입 정보를 명시해야 한다.

아이템 50. 오버로딩 타입보다는 조건부 타입을 사용하기

오버로팅 타입보다 조건부 타입을 사용하는 것이 좋다. 오버로딩 타입이 작성하기는 쉽지만, 조건부 타입은 개별 타입의 유니온으로 일반화하기 때문에 타입이 더 정확해진다. 오버로딩 타입을 작성 중이라면 조건부 타입으로 개선할 수 있을지 검토해 본다.

아이템 51. 의존성 분리를 위해 미러 타입 사용하기

작성 중인 라이브러리가 의존하는 라이브러리의 구현과 무관하게 타입에만 의존한다면, 필요한 선언부만 추출하여 작성 중인 라이브러리에 넣는 방식인 미러링(mirroring)을 고려해 보는 것도 좋다.

아이템 52. 테스팅 타입의 함정에 주의하기

타입을 테스트할 때는 함수 타입의 동일성(equality)와 할당 가능성(assignability)의 차이점을 알고 있어야 한다.
- 함수 실행만 확인하는 테스트 코드보다는 반환 타입을 체크하는 것이 더 좋은 테스트 코드다.
콜백이 있는 함수를 테스트할 때, 콜백 매개변수의 추론된 타입을 체크해야 한다. this가 API의 일부분이라면 역시 테스트해야 한다.
타입 관련 테스트에서 any를 주의한다.

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

2022.09.13 #10

타입스크립트 기능보다는 ECMAScript 기능을 사용하기

enum 열거형을 쓰면 안되는 이유

매개변수 속성

몽키 패치보다는 안전한 타입을 사용하기

devDependencies에 typescript와 @types 추가하기

타입 선언과 관련된 세 가지 버전 이해하기

API 주석에 TSDoc 사용하기

콜백에서 this에 대한 타입 제공하기

오버로딩 타입보다는 조건부 타입을 사용하기

의존성 분리를 위해 미러 타입 사용하기

테스팅 타입의 함정에 주의하기

문서에 타입 정보를 쓰지 않기

타입 주변에 null 값 배치하기

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

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

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

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

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

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

아이템 45. devDependencies에 typescript와 `@types` 추가하기

아이템 46. 타입 선언과 관련된 세 가지 버전 이해하기

아이템 47. 공개 API에 등장하는 모든 타입을 익스포트 하기

아이템 48. API 주석에 TSDoc 사용하기

아이템 49. 콜백에서 this에 대한 타입 제공하기

아이템 50. 오버로딩 타입보다는 조건부 타입을 사용하기

아이템 51. 의존성 분리를 위해 미러 타입 사용하기

아이템 52. 테스팅 타입의 함정에 주의하기

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

2022.09.13 #10

타입스크립트 기능보다는 ECMAScript 기능을 사용하기

enum 열거형을 쓰면 안되는 이유

매개변수 속성

몽키 패치보다는 안전한 타입을 사용하기

devDependencies에 typescript와 @types 추가하기

타입 선언과 관련된 세 가지 버전 이해하기

API 주석에 TSDoc 사용하기

콜백에서 this에 대한 타입 제공하기

오버로딩 타입보다는 조건부 타입을 사용하기

의존성 분리를 위해 미러 타입 사용하기

테스팅 타입의 함정에 주의하기

문서에 타입 정보를 쓰지 않기

타입 주변에 null 값 배치하기

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

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

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

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

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

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

아이템 45. devDependencies에 typescript와 @types 추가하기

아이템 46. 타입 선언과 관련된 세 가지 버전 이해하기

아이템 47. 공개 API에 등장하는 모든 타입을 익스포트 하기

아이템 48. API 주석에 TSDoc 사용하기

아이템 49. 콜백에서 this에 대한 타입 제공하기

아이템 50. 오버로딩 타입보다는 조건부 타입을 사용하기

아이템 51. 의존성 분리를 위해 미러 타입 사용하기

아이템 52. 테스팅 타입의 함정에 주의하기

아이템 45. devDependencies에 typescript와 `@types` 추가하기