TypeScript의 목표는 JavaScript 프로그램의 정적 타입 검사자이다. 코드가 실행되기 전에 실행하고(정적), 프로그램 타입이 정확한지 확인하는 도구(타입 검사)이다.
실습의 목표
- TypeScript 구문 및 패턴을 읽고 이해할 수 있음
- 중요한 컴파일러 옵션의 효과를 설명할 수 있음
- 타입 시스템 동작을 올바르게 예측할 수 있음
- 간단한 함수, 객체, 클래스에 대한 .d.ts 선언을 작성할 수 있음
JavaScript(ECMAScript)는 브라우저를 위한 스크립팅 언어로 제작되었다. JS 사용량이 점차 커지자 웹 브라우저 개발자들은 실행 엔진(동적 컴파일)을 최적화 시키고, 최적화된 것을 이용해 할 수 있는 일(API 추가)로 더 많은 웹 개발자가 JS를 사용할 수 있게 했다.
"어디서든 작동된다"라는 JS의 성질은 교차 플랫폼(Cross-platform) 개발을 위한 매력적인 선택지가 되었음에도 JavaScript에는 이상하고 놀라운 점들이 몇 존재한다.
1. JS의 동일 연산자는 ==
인수를 강제로 변환(coerces)하여 예상치 못한 동작을 유발함
if("" == 0) { } // 참, NaN발생
if(1 < x < 3) { } // 어떤 x 값이던 참
2. JS는 존재하지 않는 프로퍼티의 접근을 허용함
const obj = { width: 10, height: 15 }
const area = obj.width * obj.heigth;
수백, 수천 줄의 어플리케이션 작성 시 이러한 문제점들이 쌓이고 쌓이면 심각한 문제를 야기한다.
버그가 많은 프로그램을 아예 실행시키지 않는 언어도 있다.
TS는 정적 타입 검사자로 프로그램을 실행시키기 전, 값의 종류를 기반으로 오류를 찾는다.
const obj = { width: 10, height: 15};
const area = obj.width * obj.heigth;
// 'obj'의 타입 때문에 에러 발생
TS와 JS의 관계를 알아보자.
구문은 프로그램을 만들기 위해 코드를 작성하는 방법으로, TS는 JS의 구문이 허용되는 JS의 상위 집합 언어이다.
let a = (4
// ')'이 없으므로 '구문 오류'임.
JS코드를 TS파일에 넣어도 잘 작동한다. (TS는 JS코드를 오류로 보지 않음)
TS는 다른 종류의 값들을 사용할 수 있는 방법이 추가된 타입이 있는 상위 집합이다. 위의 예시에서 obj.heigth
는 구문 오류가 아닌 값의 종류(타입)을 잘못 써서 발생한 것이다.
console.log(4 / []);
.js
파일로 작성 시 NaN
을 출력한다. .ts
파일로 작성 시 숫자/배열
연산이 옳지 않다고 판단하고 오류를 출력한다. TS의 타입 검사자는 일반적인 오류를 최대한 많이 검출하면서 올바른 프로그램을 만들 수 있게 설계되었다. 만약 JS파일의 코드를 TS 코드로 옮기면 타입 오류를 볼 수 있다. TS는 JS의 런타임 특성을 가진 언어다.
Infinity
값을 반환한다. TS가 JS와 동일한 런타임 동작을 유지하는 이유
: 두 언어 간에 쉽게 전환할 수 있게 하기 위함임
TS의 컴파일러가 코드 검사를 마치면, 타입을 삭제하고 결과적으로 "컴파일된" 코드를 만든다. 즉 TS의 컴파일러를 통해 코드가 한 번 컴파일 되면 결과로 나온 일반 JS코드에는 타입 정보가 없는 것이다.
TS는 추론한 타입에 따라 프로그램의 특성을 변화시키지 않음으로써 타입 정보가 없다. 다시 말해 컴파일 도중에는 타입 오류가 나타날 수 있지만, 타입 시스템 자체는 프로그램이 실행될 때 작동하는 방식과 관련이 없다는 것이다.
TS는 JS와 같은 표준 라이브러리(or 외부 라이브러리)를 사용한다.
JS를 배우지 않고선 TS를 배울 수 없다. TS는 JS와 구문, 런타임 특성을 공유한다.
만약 TS에서 리스트를 정렬하는 법을 찾는 경우, TS는 컴파일-타임타입 검사자가 있는 JS 런타임이므로 JS에서 같은 방법으로 할 수 있다.
cf. TypeScript 핸드북