오늘 날 자바스크립트는 수십 년 전의 아름다운 웹 브라우저를 지원합니다.
타입스크립트를 이야기하기 전에 타입스크립트의 시발점인 JS부터 살펴보겠습니다.
자바스크립트는 별난 특성이 있지만 웹 애플리케이션과 인터넷의 놀라운 성장을 가능하게 만들었습니다.
만약 제게 완벽한 프로그래밍 언어를 제시한다면, 저는 사용자가 한 명도 없는 언어를 보여주겠습니다.
- 아네르스 하일스베르, TSConf, 2019
바닐라(Vanilla) : 중요한 언어 확장이나 프레임워크 없이 JS를 사용하는 것을 바닐라
라고 부릅니다. 순수한 자바스크립트를 의미합니다.
자바스크립트를 사용하는 개발자들의 가장 큰 불만은 핵심 기능에 있었다. 자바스크립트는 사실상 코드를 구성하는 방법에 제한이 없습니다. 이러한 자유 덕분에 프로젝트를 자바스크립트로 시작하면 매우 재미있습니다.
function paintPainting (painter, painting) {
return painter
.prepare()
.paint(painting, painter.ownMaterials)
.finish();
}
코드 베이스(소프트웨어 구성요소를 빌드할 때 사용하는 소스 코드의 전체 집합)에 대한 이해가 있거나, 함수가 반환되어야 하는지 기억하고 있거나, painting이 문자열이라고 추측할 수 도 있다.
그러나 앞선 가정이 정확하더라도 나중에 코드가 수정된다면 이 가정은 무효가 될 수 도 있다.
다른 언어는 컴파일러가 충돌할 수 있다고 판단하면 코드 실행을 거부할 수 있다. 하지만 자바스크립트처럼 충돌 가능성을 먼저 확인하지 않고 코드를 실행하는 동적 타입언어는 그렇지 않습니다.
결국 코드의 자유는 자바스크립트를 재미있게 만들기도 하지만, 우리의 코드를 안전하게 실행할 때 상당한 고통을 안겨준다.
자바스크립트 언어 사양에는 함수의 매개변수, 함수 반환, 변수 또는 다른 구성요소의 의미를 설명하는 표준화된 내용이 없다.
따라서 많은 개발자가 블록 주석으로 함수와 변수를 설명하는 JSDoc 표준을 채택했다.
/**
* Performs a painter painting a particular painting.
*
* @param {Painting} painter
* @param {string} painting
* @returns {booleen} Whether the painter painted the painting.
*/
function paintPainting(painter, painting) { /*...*/ }
JSDoc 에는 다음과 같은 주요 문제로 인해 규모가 있는 코드베이스에서 사용하기 불편합니다.
자바스크립트는 타입을 식별하는 내장된 방법을 제공하지 않고, 코드가 JSDoc 주석에서 쉽게 분리되기 때문에 코드베이스에 대한 대규모 변경을 자동화하거나 통찰력을 얻기가 매우 어렵습니다.
자바스크립트 개발자는 C#이나 자바와 같은 타입이 지정된 언어에서 클래스 멤버 이름을 변경하거나 인수의 타입이 선언된 곳으로 바로 이동할 수 있는 기능을 보고 놀란다.
→ 해석이 조금 이상한거 같다.
타입스크립트는 2010년대 초 마이크로소프트 내부에서 만들어진 후 2012년에 출시 및 오픈소스화 되었다.
타입스크립트는 네가지로 설명된다.
https://typescriptlang.org/ko/play
이 책에서 사용하는 대부분의 스니펫은 의도적으로 작고 독립적이게 만들었으므로 직접 플레이그라운드에 입력하며 재미 삼아 가지고 놀 수 있습니다.
const firstName = "Georgia";
const nameLength = firstName.length();
// ~~~~~~~~
// Error: This expression is not callable
이 코드에 타입스크립트 타입 검사기를 실행하면, 문자열의 길이 프로퍼티가 함수가 아니라 숫자라는 지식을 활용해 오류를 알려준다.
타입스크립트를 사용하면 매개변수와 변수에 제공되는 값의 타입을 지정할 수 있다. 일부 개발자는 처음에 특정 영역(Scope?)이 제한적으로 작동하는 방법을 코드에 명시적으로 작성해야한다고 생각한다.
하지만 저자는 이런 식의 “제한”은 실제로 바람직하다고 생각한다고 한다. 코드를 지정한 방법으로만 사용하도록 제한한다면, 타입스크립트는 코드의 한 영역을 변경하더라도 이 코드를 사용하는 다른 코드 영역이 멈추지 않는다는 확신을 줄 수 있다.
sayMyName 함수의 매개변수가 두개에서 하나로 변경되었지만, 함수를 호출하는 코드는 여전히 두개의 문자열을 사용해 TS 에러가 발생한다.
// 이전 코드: sayMyName(firstName, lastNameName) { ...
function sayMyName(fullName) {
console.log('You acting kind of shady, ain't callin' me ${fullNmae}');
}
sayMyName("Beyoncé", "Knowles");
//
// Error : Expected 1 argument, but got 2.
이 코드는 JS에서 오류 없이 실행되지만, 결과가 예상하는 것과 다르다. (두번째 Knowles는 결과값에서 제외된다.)
잘못된 수의 인수를 사용해서 함수를 호출하는 것은 타입 스크립트가 제한하는 자바스크립트가 가진 일종의 근시안적인 자유이다.
앞서 다뤘던 paintPainting 함수의 타입스크립트 버전을 살펴보자.
타입을 문서화하기 위한 타입스크립트 구문을 아직 살펴보지 않았지만, 코드를 문서화하는 타입스크립트의 정밀함을 다음 예제로 살펴보자.
interface Painter {
finish(): boolean;
ownMaterials: Material[];
paint(painting: string, materials: Material[]): boolean;
}
function paintPainting(painter: Painter: String): boolean { /* ... */ }
이 코드를 처음읽은 타입스크립트 개발자라면 Painter에 적어도 세 가지 속성이 있고, 그 중 두 가지는 메서드 라는 것을 이해할 것이다.
타입스크립트는 구문을 적용해 객체의 형태(shape)를 설명하고, 우수하고 강력한 시스템을 이용해 객체가 어떻게 보이는지 설명한다.
VSC 같은 편집기에서 타입스크립트로 코드를 작성하면 편집기는 타입스크립트를 더 깊이 이해합니다.(?)
이 이해를 바탕으로 편집기는 우리가 작성한 코드에 똑똑한 제안을 표시한다. (개발할 때 유용함.)
VSC 에는 자동완성 기능이 코드를 제안하는 것이 있다.
(생략)
타입스크립트 컴파일러에 타입스크립트 구문을 입력하면 타입을 검사한 후 작성된 코드에 해당하는 자바스크립트를 내보낸다.(emit)
편의상 컴파일러는 최신 자바스크립트 구문이나 이전 ECMA스크립트에 상응하는 코드로 컴파일할 수 도 있습니다.
npm i -g typescript
tsc --init
tsconfig 파일의 옵션 은 13장 ‘구성 옵션’에서 가볍게 살펴볼 예정.
하지만 중요한 특징은 tsc를 실행해 폴더의 모든 파일을 컴파일하도록 지시할 수 있고, 타입 스크립트가 모든 구성 옵션에 대해서 tsconfig.json을 참조할 수 있다는 것이다.
이렇게 작성시 에러가 뜬다.
[{
"resource": "/Users/younghoon/Code/type/index.ts",
"owner": "typescript",
"code": "2339",
"severity": 8,
"message": "'Console' 형식에 'blub' 속성이 없습니다.",
"source": "ts",
"startLineNumber": 1,
"startColumn": 9,
"endLineNumber": 1,
"endColumn": 13
}]
실제로 blub는 console에 존재하지 않지만, tsc index.ts
를 하면 index.js
를 생성한다.
매우 중요한 개념이다. 비록 코드에 타입 오류가 있었지만, 구문은 여전히 완벽하게 유효하다.
타입스크립트 컴파일러는 타입 오류와는 상관없이 입력 파일로부터 자바스크립트를 계속 생성한다.
tsconfig.json 파일 생성할 때의 또 다른 이점은 편집기에서 특정 폴더를 열었을 때, 편집기가 이제 해당 폴더를 타입스크립트 프로젝트로 인식한다는 것이다.
예를 들어 VSC에서 폴더를 열면 타입스크립트 코드를 분석하는 데 사용하는 설정은 해당 폴더의 tsconfig.json을 따르게 된다.
타입스크립트가 얼마나 훌륭한지 알았으니, 이제 타입스크립트의 몇 가지 제약에 대해 알아봅시다.(모든 도구는 어떤 영역에서 탁월하지만, 다른 영역에서는 한계가 있다.)
타입스크립트는 자바스크립트 코드를 구조화하는 데 도움이 되지만, 타입 안정성 강화를 제외하고는 해당 구조가 어떻게 보여야 하는지에 대해서 어떤 것도 강요되지 않는다. (개굳특징)
타입스크립트는 특정 대상만을 위한 독단적인 프레임워크가 아닌 모든 개발자가 사용할 수 있는 프로그래밍 언어이며, 자바스크립트에서 사용했던 아키텍쳐 패턴 중 무엇이든 사용해서 코드를 작성할 수 있고, 타입스크립트가 이를 지원한다.
타입스크립트는 클래스나 함수 사용 여부와 같은 코드 스타일 의견을 강요하지 않으며, 앵귤러, 리액트 등의 특정 애플리케이션 프레임워크와도 연관되어 있지 않다.
타입스크립트의 설계 목표는 다음과 같이 명시되어 있습니다.
타입스크립트는 자바스크립트의 동작방식을 전혀 변경하지 않는다. 타입스크립트 개발자들은 자바스크립트에 추가하지 않기 위해 노력했습니다. 이런 작업은 ECMA 스크립트 자체에서 작업 하는 기술 위원회인 TC39의 영역입니다.
타입스크립트는 코드를 빌드하는데 시간이 조금 더 걸린다.
타입스크립트 코드는 브라우저나 Node와 같은 환경에서 실행되기 전 자바스크립트로 컴파일된다. 빌드 파이프라인은 대부분 성능 저하를 무시하도록 설정됩니다. 코드에서 발생할 수 있는 오류를 분석하는 느린 타입 스크립트 기능은 실행 가능한 애플리케이션 코드 파일을 생성하는 것과는 분리된 채로 수행됩니다.
웹의 진화는 끝나지 않았고, 타입스크립트도 마찬가지이다. 웹 커뮤니티는 타입스크립트의 버그 수정과 기능 추가를 지속적으로 요청하고 있다.
타입스크립트의 기본 원칙은 거의 변함이 없겠지만, 오류메시지, 더 멋진 기능 그리고 편집기와의 통합은 시간이 지남에 따라 개선될 것이다.
자바스크립트의 주요 약점과 타입스크립트가 작동하는 방식, 타입스크립트를 시작하는 방법에 대해 알아봤었다.