" 타입스크립트는 인터프리터 언어로 실행되는 것도 아니고, (Java, C 같이)저수준 언어로 컴파일 되는 것도 아닙니다. 또 다른 고수준 언어인 ‘자바스크립트’로 컴파일되며, 실행 역시 타입스크립트가 아닌 자바스크립트로 이루어집니다. 그래서 타입스크립트와 자바스크립트의 관계는 필연적이며, 이 밀접한 관계 때문에 혼란스러운 일이 벌어지기도 합니다. " (1장 소개말 중)
아이템 1. 타입스크립트와 자바스크립트의 관계 이해하기 #
타입스크립트는 자바스크립트의 상위 집합
- 모든 ‘자바스크립트’ 는 ‘타입스크립트’ 이다. (참)
- 모든 ‘타입스크립트’ 는 ‘자바스크립트’ 이다. (거짓)
- 타입스크립트 중에는 자바스크립트가 아닌 프로그램이 존재한다고 한다.
|---------------------|
| ts |
| |------| |
| | js | |
| |------| |
| |
|---------------------|
타입스크립트는 자바스크립트의 상위집합이기 때문에, js 파일의 코드는 이미 타입스크립트라고 할 수 있다.
| 종류 | 확장자 |
|---|---|
| 자바스크립트 | .js, .jsx |
| 타입스크립트 | .ts, .tsx |
main.js→main.ts변경해도 된다.
이러한 특성은 기존 자바스크립트 코드를 타입스크립트로 마이그레이션하는 것에 엄청난 이점을 줄 수 있다.
자바스크립트에서 타입구문을 사용하는 순간부터 타입스크립트 영역으로 들어가게 된다.
// 다음 코드를 javascript 를 구동하는 노드(node) 같은 프로그램에서 실행 시 오류가 발생한다.
function greet(who: string) {
console.log('Hello, ', who);
}
// [오류 내용]
// function greet(who: string)
// ^
// SyntaxError: Unexpected token :
타입스크립트 컴파일러는 타입스크립트뿐만 아니라 일반 자바스크립트 프로그램에도 유용하다.
타입스크립트는 타입 구문(타입 선언) 없이도 다양한 오류를 잡을 수 있다. 여기에 타입 구문을 추가한다면 훨씬 더 많은 오류를 찾아낼 수 있게 되는 것이다.
// 다음 코드는 오류가 발생한다.
let city = 'new york city';
console.log(city.toUppercase());
// [오류 내용]
// TypeError: city.toUppercase is not a function
(타입 구문이 없어도) 위 코드를 ‘타입스크립트의 타입 체커’를 이용하면 다음과 같이 문제점을 빠르게 찾아낼 수 있다.
let city = 'new york city';
console.log(city.toUppercase());
// ~~~~~~~~ 'toUppercase' 속성이 'string' 형식에 없습니다.
// 'toUpperCase'을(를) 사용하시겠습니까?
타입스크립트는 초깃값으로부터 타입을 추론한다. 타입스크립트의 타입 추론은 중요한 부분이다. (3장에서 자세히)
내가 생각한 핵심은 다음과 같다.
" 타입스크립트에게 타입을 선언하여 개발자의 ‘의도’를 전달한다. ‘의도’를 정확히 전달할 수록 타입스크립트가 정확하게 확인해주는 것이다. 이러한 ‘의도’ 전달을 자바, 코틀린 등 기존에 사용한 컴파일 언어에서 꾸준히 해온 것이다. “
타입 시스템의 목표 중 하나는 런타임에 오류를 발생시킬 코드를 미리 찾아내는 것이다.
다만, 타입 체커가 모든 오류를 찾아내지는 않는다.
타입스크립트는 자바스크립트 런타임 동작을 모델링한다. (설계한다?)
따라서, 런타임 오류를 발생시키는 코드를 찾아내려고 한다.
하지만, 모든 오류를 찾아내리라 기대하면 안된다. 타입 체커를 통과하면서 런타임 오류를 발생시키는 코드는 충분히 존재 가능하다.
기존 자바스크립트의 ‘엄격하지 않는 특징’을 선호한다면, 타입스크립트를 선택하는 것을 고민해봐야 한다.
이것은 온전히 (개발자의)취향의 차이이다.