1장

• 타입스크립트는 자바스크립트로 컴파일과 실행이 이뤄집니다.

타입스크립트와 자바스크립트의 관계 이해하기

• 자바스크립트는 타입스크립트의 부분 집합입니다.

• js 또는 jsx 파일을 ts, tsx로 바꾼다고 달라지는 점은 없습니다. 이는 마이그레이션에 엄청난 이점이 됩니다.

• 타입스크립트이지만 자바스크립트가 아닌 경우가 존재합니다. (타입을 명시하는 추가적인 문법들)

• 타입스크립트는 타입 체크를 통해 문제점을 찾아줍니다. (타입 추론을 이용해서)
• 타입에 따른 메서드
• 객체의 키값 (어느쪽이 오타인지는 판정하지 못합니다.)

• 명시적인 타입 선언으로 (interface or type) 잠재적 문제를 찾을 수 있다.

• 타입체커를 통과한 프로그램도 오류가 있다고 판단되는 경우 타입스크립트에서 이를 표시함

• 타입스크립트는 타입에 초점을 맞추고 정확성은 Reason, Elm 같은 언어를 사용하는 것이 났다.

타입스크립트 설정 이해하기

1. 커맨드 라인

tsc --noImplicitAny program.ts

2. tsconfig.json (tsc —init 실행)

{
	"CompilerOptions": {
		"noImplicitAny": true
	}
}

• noImplicitAny - 암시적 any 타입으로 간주되는 것을 막습니다.

• strickNullChecks - null or undefined 가 허용되는 것을 확인해주는 설정
• 명시적인 방법으로는 유니언을 활용해 number | null 허용할 수 있음
• 허용하지 않는다면?
null check, or 단언문(assertion) 추가



• strickNullChecks 사용하려면 noImplicitAny를 먼저 설정해야합니다.
• 이 두개를 모두 체크하고 싶다면 strict를 설정하자

코드 생성과 타입이 관계없음을 이해하기

• 타입스크립트 컴파일러의 역할
• 최신 타입스크립트/자바스크립트를 브라우저에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일
• 코드의 타입 오류를 체크

• 타입 오류가 있는 코드도 컴파일이 가능
• 타입 체크와 독립이기에 컴파일이 가능
• C나 자바는 컴파일과 타입체크가 동시에 이뤄짐
• 오류가 있을 때 컴파일하지 않으려면 tsconfig.json에 noEmitOnError를 설정하거나 빌드 도구에 동일하게 적용하면 된다.

• 런타임에는 타입 체크가 불가능
• 해결법 속성 존재를 체크
• 태그 기법: 런타임에서 접근 가능한 타입 정보를 명시적으로 저장하는 방법
• 타입(런타임 접근 불가)과 값(런타임 접근 가능)을 둘다 사용하는 방법은 타입을 클래스로 만들면 된다.
• 인터페이스는 타입으로만 사용 가능하지만 클래스로 선언하면 타입과 값으로 모두 사용할 수 있다.

• 타입 연산은 런타임에 영향을 주지 않는다.
• 타입 단언문 as number 은 타입 연산으로 런타임 동작에는 영향을 주지 않습니다.
• 타입을 체크하고 자바스크립트로 연산하여 변환을 수행해야 값을 정제할 수 있음

• 런타임 타입은 선언된 타입과 다를 수 있다.
• 네트워크 호출을 통해 받은 값을 함수에 사용하는 경우 런타임에서는 타입이 맞지 않을 수 있음

• 타입스크립트 타입으로는 함수를 오버로드할 수 없다.
• C++ 같은 언어는 매개변수만 다른 여러 버전의 함수를 허용, 타입 스크립트에서는 함수 오버로딩은 불가
• 타입 수준의 오버로딩만 지원, 여러개의 타입 선언문을 작성할수 있으나 구현체는 하나 뿐

• 타입스크립트 타입은 런타임 성능에 영향을 주지 않음
• 타입과 타입 연산자는 자바스크립트 변환 시점에서 제거되기 때문에 영향이 없다.
• 런타임에는 오버헤드가 없으나 컴파일러 빌드타임에는 오버헤드가 있음, 오버헤드가 크다면 transpile only를 체크
• 호환성과 성능 오버헤드를 선택하는 과정에서도 타입과는 무관함

구조적 타이핑 익숙해지기

• 자바스크립트는 덕 타이핑 기반, 함수의 매개변수 값이 모두 제대로 주어진다면 그 값이 어떻게 만들어졌는지 신경쓰지 않고 사용

• 타입스크립트는 이를 모델링하기 위해 구조적 타이핑을 지원

• 어떤 타입 선언과 구조가 같다면 관계를 선언하지 않아도 함수가 동작함 이를 구조적 타이핑이라고함

• 이러한 구조적 타이핑 때문에 문제가 발생하기도함

• 어떤 함수 안에서 선언되는 변수, 추가적으로 제공되는 정보로 잘못된 결과값을 받을 수 있음

• 클래스에서도 구조적 타이핑을 따름 인스턴스가 예상과 다를 수 있다.

• 그럼에도 테스트를 작성할 때에는 구조적 타이핑이 유리하다

any 타입 지양하기

• 타스의 any를 통해 점진적이고 선택적이다.

• any 타입에는 타입 안전성이 없다.

• any는 함수 시그니처를 무시한다.

• any 타입에는 언어 서비스가 적용되지 않는다.
• 심벌에 타입이 있다면 자동완성과 적절한 도움말을 제공한다.
• 편집기의 Rename Symbol을 클릭해서 인터페이스와 관련된 내용을 한번에 수정할 수 있다.

• any 타입은 코드 리팩터링 때 버그를 감춥니다.
• any를 사용하면 잡을 오류도 놓친다~

• any는 타입 설계를 감춘다
• 설계가 보이도록 구체적으로 작성하는 것이 필요하다

• any는 타입시스템의 신뢰도를 떨어뜨린다.