이펙티브 타입스크립트 3장

[Choozii]

19. 추론 가능한 타입을 사용해 장황한 코드를 방지

• 타입스크립트가 타입을 추론 가능하다면 타입 구문을 작성하지 말라
• 함수/메서드의 시그니처에는 타입 구문 적기, 함수 내부의 지역 변수에는 타입 구문을 적지 않기
  • 타입 구문을 최소화하고 코드를 읽는 사람이 구현 로직에 집중할 수 있게 하는 것이 좋음
• 객체 리터럴과 함수 반환에는 타입을 명시하자 -> 정확한 위치에 오류가 표시됨

20. 다른 타입에는 다른 변수 사용하기

• 변수의 값은 바뀔 수 있지만 타입은 일반적으로 바뀌지 않음
• 타입이 다른 값을 다룰때에는 변수를 분리하는게 좋다.

21. 타입 넓히기

• 타입스크립트가 상수의 타입을 추론할 때 '넓히기'를 사용함
  • ex. let x = 'x' 일 때, 타입스크립트는 x의 타입을 string으로 추론
• const를 사용하면 더 좁은 타입으로 추론됨
  • const x = 'x'로 할당할 경우, x는 재할당될 수 없으므로 타입을 'x'로 추론
• 값 뒤에 as const를 작성하면 타입스크립트는 최대한 좁은 타입으로 추론함

22. 타입 좁히기

• if문으로 특정 타입의 데이터만 걸러내기
  • 객체에 존재하는 속성으로 체크
  • instanceof를 사용
  • Array.isArray 같은 내장 함수 사용
  • 타입에 명시적 태그를 추가하기 ex. interface UploadEvent {type : 'upload'; filename : string; contents : string; }

23. 객체 생성하기

• 속성을 제각각 추가하지 말고 한꺼번에 객체로 만들기 -> 타입 추론에 유리
• 객체를 생성할 때 객체 전개 연산자(...)를 활용
• 제각각 나눠서 만들어야 한다면 as를 사용해 타입 체커를 통과하게 만들수 있음

[humonnom]

24.일관성 있는 별칭 사용하기

• 별칭을 만들면 별칭과 본래 속성 값 사이의 관계 때문에 혼란을 줄 여지가 있다.(읽기 비용 up)
• 그러므로 사용에 주의해야 한다.
• 별칭 보다는 비구조화를 사용하면 읽는데 드는 비용을 줄일 수 있다.
• 혼란을 주는 사용예시
  1. 별칭으로 값을 변경한 경우 원본에도 적용되는데, 원본의 변수명만 따라가며 읽은 경우 변경 사항을 예측 못할 수 있음

     
     const originObj = { list: [1, 2, 3] };

const aliasForList = originObj.list;

aliasForList[0] = 42;

console.log(originObj.list);

2. 구조분해할당 이후에 원본을 변경하면 변경사항이 구조분해할당 된 변수에는 적용되지 않으므로 원본과 차이가 생김
```ts
// list: [42, 2, 3]

const { list } = originObj;

originObj.list = [100, 200, 300];

console.log(originObj.list); // [42, 2, 3]
console.log(list); // [100, 200, 300]

• 질문: 135p 맨위 세줄 이해가 안가요.

• 타입스크립트의 정제 책에서 정제라는 표현을 쓰고 있는데 값이 한번 정제가 된 경우, 함수를 거칠때 마다 타입을 정제해야 한다면 비용이 많이 들기 때문에 정제를 무효화하지 않고 유지한다. 그런데 객체의 속성을 그대로 사용하면 함수를 거친이후 해당 속성이 삭제될 가능성이 있다. 그러므로 구조분해할당 등 지역변수를 사용하는 것이 타입의 유지 측면에서는 일관될 수 있다.(그러나 해당 변수의 값이 원본과 달라질 수 있는 가능성이 있음)

const { name } = props

지역변수	속성을 그대로 사용
name	props.name

• 별칭을 사용하는 것이 사람에게도 코드 읽기의 어려움을 증가시키지만, 타입스크립트의 타입 좁히기에도 어려움을 준다.

25. 비동기 코드에는 콜백 대신 async 함수 사용하기

• callback hell === pyramid of doom

version	new
ES2015	프로미스
ES2017	async await

• 런타임에 어떻게 되든 상관없이 async, await으로 작성하면 컴파일 해준다.

  • ES2015(es6)으로 컴파일하면 generator를 이용해서 __awaiter라는 함수를 만들어냄
  • ES2015 이전 버전으로 컴파일하면 generator가 도입되기 전이기 때문에 __generator를 만들어냄

• 콜백 스타일 보다는 async, await 사용 권장(타입 구문이 적게 필요)

• 프로미스를 직접 생성해서 사용하기 보다는 async, await 사용 권장(덜 복잡하고 async는 무조건 Promise를 반환하므로 타입 추론이 쉽다.)

• 함수는 어떨 때는 동기로, 어떨 때는 비동기로 사용되어서는 곤란하다.

• 반(harf)동기: 반환 값을 예측할 수 없다 => 함수의 리턴값은 일종의 약속(계약)인데 그것이 위반됨

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

• let으로 선언하는 것과 const로 선언하는 것의 차이

  const lang = 'JS' // 타입은 'JS'
  let lang = 'JS' // 타입은 string

• const 타입 넓히기 복습!

  • 객체를 const로 선언하면 각 요소는 let으로 선언된 것처럼 다룸
  • const a = {b: 'b', c: 2}
    • b에 다른 string을 대입할 수 있음
    • 하지만 string이 아닌 타입을 대입하면 에러 남

• const, as const의 차이

  • const로 선언하는 것: shallow 얕은 상수
  • ts의 as const 문법을 사용하는 것: deeply 깊은 상수

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

• Underscore, Lodash, Ramda 같은 라이브러리 소개
• 일부 기능은 순수 JS로 구현, 일부는 Lodash에서 제공 => 루프를 대체할 수 있는데, ts와 함께 사용하면 유용함

왜 ?

• 순수 JS만 사용하여 코드를 짜면 절차형으로 짜거나, 함수형으로 짜도 알아보기 어렵다.
• Lodash에서 제공하는 함수를 사용하면 코드 수가 줄어들고 알아보기 편하다.
• 서드파티 라이브러리를 도입하는데 비용이 많이 들면 신중히 생각해야하는데, ts랑 함께 쓴다면 도입하는 것이 낫다.
• 타입 정보를 참고하면서 작업할 수 있고, 타입 구문을 작성할 필요가 줄어듬 => 오히려 시간이 적게 든다 => 유리함