필수가 아닌 의존성을 분리할 때는 구조적타이핑을 사용하면 된다.

CSV 파일을 파싱하는 라이브러리를 작성한다고 가정해보자.

CSV 파일의 내용을 매개변수로 받고 열 이름을 값으로 매핑하는 객체들을 생성하여 배열로 반환한다. 그리고 NodeJS 사용자를 위해 매개변수에 Buffer 타입을 허용한다.

function parseCSV(contents: string | Buffer): { [column: string]: string }[] {  
  if (typeof contents === 'object') {  
    // It's a buffer  
    return parseCSV(contents.toString('utf8'))  
  }  // COMPRESS  
  return []  
  // END  
}

Buffer 타입은 npm install --save-dev @types/node 를 통해 얻을 수 있다.

그러나 @types/node를 devDependencies로 포함하면 다음 두 그룹의 라이브러리 사용자들에게 문제가 생긴다.

• @types와 무관한 자바스크립트 개발자
• NodeJS와 무관한 타입스크립트 웹 개발자

각자가 필요한 모듈만 사용할 수 있도록 구조적타이핑을 적용할 수 있다.

interface CsvBuffer {  
  toString(encoding: string): string  
}  
function parseCSV(contents: string | CsvBuffer): { [column: string]: string }[] {  
  // COMPRESS  
  return []  
  // END  
}

CsvBuffer 는 Buffer 인터페이스보다 훨씬 짧으면서도 실제로 필요한 부분만을 떼어 내어 명시했다. 또한 해당 타입이 Buffer와 호환되기 때문에 NodeJS 프로젝트에서는 실제 Buffer 인스턴스로 parseCSV를 호출하는 것이 가능하다.

공개한 라이브러리를 사용하는 자바스크립트 사용자가 @types 의존성을 가지지 않게 해야 한다. 그리고 웹 개발자가 NodeJS 관련된 의존성을 가지지 않게 해야 한다.

만약 작성중인 라이브러리가 의존하는 라이브러리의 구현과 무관하게 타입에만 의존한다면, 필요한 선언부만 추출하여 작성중인 라이브러리에 넣는 것(미러링 , mirroring)을 고려해보는 것도 좋다.

NodeJS 기반 타입스크립트 사용자에게는 변화가 없지만, 웹 기반이나 자바스크립트 등 다른 모든 사용자에게는 더 나은 사양을 제공할 수 있다.

다른 라이브러리의 타입이 아닌 구현에 의존하는 경우에도 동일한 기법을 적용할 수 있고 타입의존성을 피할 수 있다. 그러나 프로젝트의 의존성이 다양해지고 필수 의존성이 추가됨에 따라 미러링기법을 적용하기 어려워진다.

다른 라이브러리의 타입 선언의 대부분을 추출해야 한다면, 차라리 명시적으로 @types 의존성을 추가하는 게 낫다.

타입을 테스트할 때는 특히 함수 타입의 동일성(equality)과 할당 가능성 (assignability) 의 차이점을 알고 있어야 한다.

타입 선언도 테스트를 거쳐야 한다. 그러나 타입 선언을 테스트하기는 매우 어렵다.

그래서 타입 선언에 대한 테스트코드를 작성할 때 타입스크립트가 제공하는 도구를 사용하여 단언문으로 때우기 십상이지만, 이런 방법에는 몇 가지 문제가 있다.

궁극적으로는 dtslint 또는 타입 시스템 외부에서 타입을 검사하는 유사한 도구를 사용하는 것이 더 안전하고 간단하다.

유틸리티 라이브러리에서 제공하는 map 함수의 타입 선언을 작성한다고 가정

declare function map<U, V>(array: U[], fn: (u: U) => V): V[]

타입 선언이 예상한 타입으로 결과를 내는지 체크할 수 있는 한 가지 방법은 함수를 호출하는 테스트 파일을 작성하는 것이다. (구현체를 위한 별도의 테스트는 있다고 가정)

map(['2017', '2018', '2019'], v => Number(v))

이 코드는 오류 체크를 수행하지만 허점이 존재한다.

예를 들어 map의 첫 번째 매개변수에 배열이 아닌 단일 값이 있었다면 매개변수의 타입에 대한 오류는 잡을 수 있다. 그러나 반환값에 대한 체크가 누락되어 있기 때문에 완전한 테스트라고 할 수 없다.

콜백이 있는 함수를 테스트할 때, 콜백 매개변수의 추론된 타입을 체크해야 한다. 또한 this가 API의 일부분이라면 역시 테스트해야 한다.

반환값을 특정 타입의 변수에 할당하여 간단히 반환 타입을 체크할 수 있는 방법을 알아보자.

declare function map<U, V>(array: U[], fn: (u: U) => V): V[]  
const lengths: number[] = map(['john', 'paul'], name => name.length)

이 코드는 일반적으로 불필요한 타입 선언에 해당한다. 그러나 테스트 코드 관점에서는 중요한 역할을 하고 있다.

number[] 타입 선언은 map 함수의 반환 타입이 number[]임을 보장한다.

타입 관련된 테스트에서 any를 주의해야 한다. 더 엄격한 테스트를 위해 dtslint같은 도구를 사용하는 것이 좋다.

declare module 'overbar';

이 선언은 전체 모듈에 any 타입을 할당한다. 따라서 테스트는 전부 통과하겠지만, 모든 타입 안전성을 포기하게 된다. 더 나쁜 점은, 해당 모듈에 속하는 모든 함수의호출마다 암시적으로 any 타입을 반환하기 때문에 코드 전반에 걸쳐 타입 안전성을 지속적으로 무너뜨리게 된다는 것이다.

noImplicitAny를 설정하더라도 타입 선언을 통해 여전히 any 타입이 생겨나게 된다. 타입 시스템 내에서 암시적 any타입을 발견해 내는 것은 매우 어렵다.

이러한 어려움 때문에 타입 체커와 독립적으로 동작하는 도구를 사용해서 타입 선언을 테스트 하는 방법이 권장된다.

DefinitelyTyped 의 타입 선언을 위한 도구는 dtslint 이다. dtslint 는 특별한 형태의 주석을 통해 동작한다.

declare function map<U, V>(array: U[], fn: (this: U[], u: U, i: number, array: U[]) => V): V[]  
const beatles = ['john', 'paul', 'george', 'ringo']  
map(  
  beatles,  
  function (  
    name, // $ExpectType string  
    i, // $ExpectType number  
    array, // $ExpectType string[]  
  ) {  
    this // $ExpectType string[]  
    return name.length  
  },  
) // $ExpectType number[]

dtslint는 할당 가능성을 체크하는 대신 각 심벌의 타입을 추출하여 글자 자체가 같은지 비교한다.

일반적으로 타입스크립트 코드에서 모든 타입 정보를 제거하면 자바스크립트가 되지만, 열거형, 매개변수 속성, 트리플 슬래시 임포트, 데코레이터는 타입 정보를 제거한다고 자바스크립트가 되지는 않는다.

많은 언어에서 몇몇 값의 모음을 나타내기 위해 열거형을 사용한다. 타입스크립트에서도 열거형을 사용할 수 있다.

enum Flavor {  
  VANILLA = 0,  
  CHOCOLATE = 1,  
  STRAWBERRY = 2,  
}  
  
let flavor = Flavor.CHOCOLATE // 타입이 Flavor  
  
Flavor // 자동완성 추천: VANILLA, CHOCOLATE, STRAWBERRY  
Flavor[0] // 값이 "VANILLA"

그러나 타입스크립트의 열거형은 몇 가지 문제가 있다. 타입스크립트의 열거형은 다음 목록처럼 상황에 따라 동작한다.

• 숫자 열거형(앞 예제의 Flavor)에 0, 1, 2 외의 다른 숫자가 할당되면 매우 위험하다. ( 이 방법은 원래 비트 플래그 구조를 표현하기 위해 설계되었다. )
• 상수 열거형은 보통의 열거형과 달리 런타임에 완전히 제거된다. 앞의 예제를 const enum Flavor로 바꾸면 컴파일러는 Flavor.CHOCOLATE을 0으로 바꿔버린다. 이런 결과는 기대하지 않은 것이며, 문자열 열거형과 숫자 열거형과 전혀 다른 동작이다.
• preserveConstEnums 플래그를 설정한 상태의 상수 열거형은 보통의 열거형처럼 런타임 코드에 상수 열거형 정보를 유지한다.
• 문자열 열거형은 런타임의 타입 안전성과 투명성을 제공한다. 그러나 타입스크립트의 다른 구조적 타이핑이 아닌 명목적 타이핑을 사용한다.

일반적으로 클래스를 초기화할 때 속성을 할당하기 위해 생성자의 매개변수를 사용한다.

class Person {  
  name: string  
  constructor(name: string) {  
    this.name = name  
  }  
}

타입스크립트는 더 간결한 문법을 제공한다.

class Person {  
  constructor(public name: string) {}  
}

예제의 public name 은 '매개변수 속성' 이라고 불리며, 멤버 변수로 name을 선언한 이전 예제와 동일하게 동작한다.

그러나 매개변수 속성과 관련된 몇 가지 문제점이 존재한다.

• 일반적으로 타입스크립트 컴파일은 타입 체커가 이루어지므로 코드가 줄어들지만, 매개변수 속성은 코드가 늘어나는 문법이다.
• 매개변수 속성이 런타임에는 실제로 사용되지만, 타입스크립트 관점에서는 사용되지 않는 것처럼 보인다.
• 매개변수 속성과 일반 속성을 섞어서 사용하면 클래스의 설계가 혼란스러워진다.

매개변수 속성을 사용하는 것이 좋은지에 대해서는 찬반 논란이 있다. 글쓴이는 매개변수 속성을 선호하지 않지만, 어떤 이들은 코드양이 줄어 들어서 좋아하기도 한다.

Node.js : require 와 module.exports 을 사용 AMD : define 함수와 콜백을 사용 타입스크립트 : module 키워드 와 '트리플 슬래시' 임포트를 사용

ECMAScript2015 가 공식적으로 모듈시스템 을 도입한 이후 타입스크립트는 충돌을 피하기 위해 module과 같은 기능을 하는 namespace 키워드를 추가했다.

namespace foo {  
  function bar() {}  
}

/// <reference path="oter.ts"/>
foo.bar();

트리플슬래시임포트 와 module 키워드는 호환성을 위해 남아있을 뿐이며, 이제는 ECMAScript2015 스타일의 모듈(import와 export)을 사용해야 한다.

타입스크립트의 역할을 명확하게 하려면, 열거형, 매개변수 속성, 트리플 슬래시 임포트, 데코레이터는 사용하지 않는 것이 좋다.

데코레이터 는 처음에 앵귤러 프레임워크를 지원하기 위해 추가되었으며 tscondig.json에 experimetalDecorators 속성을 설정하고 사용해야 한다.

앵귤러를 사용하거나 애너테이션이 필요한 프레임워크를 사용하고 있는게 아니라면, 데코레이터가 표준이 되기 전까지는 타입스크립트에서 데코레이터를 사용하지 않는게 좋다.

객체를 순회할 때, 키가 어떤 타입인지 정확히 파악하고 있다면 let k: keyof 와 for-in 루프를 사용하자. 함수의 매개변수로 쓰이는 객체에는 추가적인 키가 존재할 수 있다는 점을 명심하자.

이해를 돕기 위해 인터페이스와 함수가 가미된 다른 예제를 살펴보자.

interface ABC {  
  a: string  
  b: string  
  c: number  
}  
  
function foo(abc: ABC) {  
  for (const k in abc) {  
    // const k: string  
    const v = abc[k]  
    // ~~~~~~ Element implicitly has an 'any' type  
    //        because type 'ABC' has no index signature  }  
}

k 에 대하여 오류가 발생했다. 이와 같은 오류는 (let k: keyof ABC) 같은 선언으로 오류를 제거할 수 있다.

객체를 순회하며 키와 값을 얻는 일반적인 방법은 Object.entries 를 사용하는 것이다.

골치 아픈 타입 문제 없이, 단지 객체의 키와 값을 순회하고 싶다면 어떻게 해야 할까? Object.entries 를 사용하면 된다.

interface ABC {  
  a: string  
  b: string  
  c: number  
}  
function foo(abc: ABC) {  
  for (const [k, v] of Object.entries(abc)) {  
    k // Type is string  
    v // Type is any  
  }  
}

자바스크립트를 사용할 때는 신경쓰지 않았겠지만, DOM에는 타입 계층 구조가 있다. DOM 타입은 타입스크립트에서 중요한 정보이며, 브라우저 관련 프로젝트에서 타입스크립트를 사용할 때 유용하다.

Node, Element, HTMLElement, EventTarget 간의 차이점, Event와 MouseEvent 차이점을 알아야한다.

다음 HTML 코드를 보자.

<p id="quote">and <i>yet</i> it moves</p>

브라우저에서 자바스크립트 콘솔을 열고 p 엘리먼트의 참조를 얻어 보면, HTMLParagraphElement 타입이라는 것을 알 수 있다.

const p = document.getElementByTagName('p')[0];
p instanceof HTMLParagraphElement
// 참 true

HTMLParagraphElement 는 HTMLElement의 서브타입이고 HTMLElement는 Element의 서브 타입이다. 또한 Element는 Node의 서브타입이고 Node는 EventTarget의 서브 타입이다.

계층 구조에 따른 타입의 몇 가지 예시

DOM 엘리먼트와 이벤트에는 충분히 구체적인 타입 정보를 사용하거나, 타입스크립트가 추론할 수 있도록 문맥 정보를 활용해야 한다.

보통은 HTML 태그 값에 해당하는 'button' 같은 리터럴 값을 사용하여 DOM에 대한 정확한 타입을 얻을 수 있다. 예를 들면 다음과 같다.

document.getElementsByTagName('p')[0] // HTMLParagraphElement  
document.createElement('button') // HTMLButtonElement  
document.querySelector('div') // HTMLDivElement

그러나 항상 정확한 타입을 얻을 수 있는 것은 아니다. 특히 document.getElementById에서 문제가 발생하게 된다.

document.getElementById('my-div') // HTMLElement

일반적으로 타입 단언문은 지양해야하지만 DOM 관련해서는 타입스크립트보다 우리가 더 정확히 알고 있는 경우이므로 단언문을 사용해도 좋다.

#my-div 가 div 태그라는 것을 알고있으므로 문제가 되지 않는다.

document.getElementById('my-div') as HTMLDivElement

stritNullChecks가 설정된 상태라면, document.getElementById가 null인 경우를 체크해야한다. 실제 코드에서 document.getElementById가 null일 가능성이 있다면 if 분기문을 추가하도록 하자.

document.getElementById('my-div')!;

EventTarget 이후에는 다음 오류가 발생했다. 오류의 원인을 살펴보자.

function handleDrag(eDown: Event) {  
  // ...  
  const dragStart = [eDown.clientX, eDown.clientY]  
  // ~~~~~~~                Property 'clientX' does not exist on 'Event'  
  //                ~~~~~~~ Property 'clientY' does not exist on 'Event'  // ...}

표에서 살펴봤던 EventTarget 타입의 계층 구조뿐 아니라, Event 타입에도 별도의 계층 구조가 있다. Mozilla 문서에는 52개 이상의 Event 종류가 나열되어 있다.

Event는 가장 추상화된 이벤트이다. 더 구체적인 타입들은 다음과 같다.

• UIEvent : 모든 종류의 사용자 인터페이스 이벤트
• MouseEvent : 클릭처럼 마우스로부터 발생되는 이벤트
• TouchEvent : 모바일 기기의 터치 이벤트
• WheelEvent : 스크롤 휠을 돌려서 발생되는 이벤트
• KeyboardEvent : 키 누름 이벤트

clientX, clientY 에서 발생한 오류의 원인은, handleDrag 함수의 매개변수는 Event로 선언된 반면 clientX, clientY 보다 구체적인 MouseEvent 타입에 있기 때문이다.

'mousedown' 이벤트 핸들러를 인라인 함수로 만들면 타입스크립트는 더 많은 문맥 정보를 사용하게 되고, 대부분의 오류를 제거할 수 있다.

또한 매개변수 타입을 Event 대신 MouseEvent 로 선언할 수 있다.

다음 예제는 방금 언급한 인라인 함수와 이벤트 타입 변경을 적용해서 오류를 제거한 코드이다.

function addDragHandler(el: HTMLElement) {  
  el.addEventListener('mousedown', eDown => {  
    const dragStart = [eDown.clientX, eDown.clientY]  
    const handleUp = (eUp: MouseEvent) => {  
      el.classList.remove('dragging')  
      el.removeEventListener('mouseup', handleUp)  
      const dragEnd = [eUp.clientX, eUp.clientY]  
      console.log(  
        'dx, dy = ',  
        [0, 1].map(i => dragEnd[i] - dragStart[i]),  
      )  
    }  
    el.addEventListener('mouseup', handleUp)  
  })  
}

public, protected, private 접근 제어자는 타입 시스템에서만 강제될 뿐이다. 런타임에는 소용이 없으며 단언문을 통해 우회할 수 있다. 접근 제어자로 데이터를 감추려고 해서는 안된다.

자바스크립트는 클래스에 비공개 속성을 만들 수 없다. 많은 이가 비공개속성임을 나타내기 위해 언더스코어 _ 를 접두사로 붙이던 것이 관례로 인정될 뿐이었다.

class Foo {
	_private = 'secret123';
}

그러나 속성에 언더스코어를 붙이는 것은 단순한 비공개라고 표시한 것뿐이다. 따라서 일반적인 속성과 동일하게 클래스 외부로 공개되어 있다는 점을 주의해야한다.

const f = new Foo();
f._private; // 'secret123'

타입스크립트에는 public, protected, private 접근 제어자를 사용해서 공개규칙을 강제하는 것으로 오해할 수 있다.

class Diary {  
  private secret = 'cheated on my English test'  
}  
  
const diary = new Diary()  
diary.secret  
// ~~~~~~ Property 'secret' is private and only  
//        accessible within class 'Diary'

그러나 public, protected, private 같은 접근제어자는 타입스크립트 키워드이기 때문에 컴파일 후에는 제거된다

확실히 데이터를 감추고 싶다면 클로저를 사용해야한다.

declare function hash(text: string): number  
  
class PasswordChecker_ {  
  checkPassword: (password: string) => boolean  
  constructor(passwordHash: number) {  
    this.checkPassword = (password: string) => {  
      return hash(password) === passwordHash  
    }  
  }  
}  
  
const checker = new PasswordChecker(hash('s3cret'))  
checker.checkPassword('s3cret') // Returns true

앞의 코드를 살펴보면 PasswordChecker의 생성자 외부에서 passwordHash 변수에 접근할 수 없기 때문에 정보를 숨기는 목적을 달성했다.

class PasswordChecker {
	#passwordHash: number;
	constructor(passwordHash: number) {
		this.#passwordHash = passwordHash;
	}
	checkPassword(password: string) {
		return hash(password) === this.#passwordHash;
	}
}

const checker = new PasswordChecker(hash('s3cret'));
checker.checkPassword('secret'); // false
checker.checkPassword('s3cret'); // true

혹은 접두사 # 을 붙여서 타입 체크와 런타임 모두에서 비공개로 만드는 역할을 한다.

만약 설계 관점의 캡슐화가 아닌 '보안'에 대해 걱정하고 있다면, 내장된 프로토타입 함수에 대한 변조 같은 문제를 알고 있어야 한다.

원본 코드가 아닌 변환된 자바스크립트 코드를 디버깅하지 말자. 소스맵을 사용해서 런타임에 타입스크립트 코드를 디버깅하자. 또한, 소스맵이 최종적으로 변환된 코드에 완전히 매핑되었는지 확인하자.

타입스크립트 코드를 실행한다는 것은, 엄밀히 말하자면 타입스크립트 컴파일러가 생성한 자바스크립트 코드를 실행한다는 것이다.

사실 컴파일러뿐 아니라 압축기(minifier)나 전처리기(preprocessor)처럼, 기존 코드를 다른 형태의 코드로 변환하는 도구들에게도 모두 해당된다.

이러한 변호나 과정들이 투명하고 직관적이라면 이상적일 것이다. 자바스크립트 코드를 살펴볼 필요 없이 마치 타입스크립트 코드가 직접 실행되는 것처럼 느껴진다면 말이다.

하지만 현실은 그렇지 못하다.

디버깅이 필요한 시점에 비로소 타입스크립트가 직접 실행되는 것이 아니라는 사실을 깨닫게 될것이다.

디버거는 런타임에 동작하며, 현재 동작하는 코드가 어떤 과정을 거쳐서 만들어진 것인지 알지 못한다. 디버깅을 하면 보게되는 코드는 전처리기, 컴파일러, 압축기를 거친 자바스크립트 코드일 것이다.

이렇게 변환된 자바스크립트 코드는 복잡해 디버깅하기 매우 어렵다.

디버깅 문제를 해결하기위해 브라우저 제조사들은 서로 협력하여 소스맵 이라는 해결책을 내놓았다.

소스맵은 변환된 코드의 위치와 심벌들을 원본 코드의 원래 위치와 심벌들로 매핑한다. 대부분의 브라우저와 많은 IDE가 소스맵을 지원한다.

코드가 복잡하게 변환된다면 소스맵이 필요하다. 타입스크립트가 소스맵을 생성할 수 있도록 tsconfig.json 에서 sourceMap 옵션을 설정하면 ts 파일에 대해서 .js .js.map 두 개의 파일을 생성한다.

.js.map 파일이 바로 소스맵이다.

소스맵이 .js 파일과 같이 있으면 브라우저에서 디버거에서 새로운 index.ts 파일이 나타난다. 이제 원하는 대로 브레이크포인트를 설정할 수 있고 변수를 조사할 수 있다.

소스맵에 원본 코드가 그대로 포함되도록 설정되어 있을 수도 있다. 공개되지 않도록 설정을 확인하도록 하자.

소스맵은 다음과 같은 사항들이 있다.

• 타입스크립트와 함께 번들러나 압축기를 사용하고 있다면, 번들러나 압축기가 각자의 소스맵을 생성하게 된다. 이상적인 디버깅 환경이 되려면 생성된 자바스크립트가 아닌 원본 타입스크립트 소스로 매핑되도록 해야한다. 번들러가 기본적으로 타입스크립트를 지원한다면 별도 설정없이 잘 동작해야한다. 그렇지 않다면 번들러가 소스맵을 인식할 수 있도록 추가적인 설정이 필요하다.
• 상용 환경에 소스맵이 유출되고 있는지 확인해야한다. 디버거를 열지 않는 이상은 소스맵이 로드되지 않으므로 실제 사용자에게는 성능 저하는 발생하지 않는다. 그러나 소스맵에 원본 코드의 인라인 복사본이 포함되어있다면 공개해서는 안될 내용이 들어있을 수 있다. 저질 주석이나 내부 버그 추적을 위한 URL을 공개할 필요가 없다.

NodeJS 프로그램의 디버깅에도 소스맵을 사용할 수 있다. 보통 편집기가 자동 인식하거나 NodeJS 프로세스를 브라우저 디버거와 연결하면 된다. 자세한 내용은 NodeJS문서를 참고하도록하자.