TypeScript

타입스크립트는 자바스크립트의 상위 집합이다. 모든 자바 스크립트는 타입스크립트이지만, 타입스크립트는 별도의 문법을 가지고 있기 때문에 일반적으로 유효한 자바스크립트 프로그램은 아닙니다.런타임 오류를 발생시키는 코드를 찾아내지만, 모든 오류를 찾아내지는 못합니다. 타입

아이템6) 편집기를 사용하여 타입시스템 탐색하기 편집기에서 타입스크립트 언어 서비스를 적극 활용해야 합니다. 편집기를 사용하면 어떻게 타입시스템이 동작하는지, 그리고 타입스크립트가 어떻게 타입을 추론하는지 개념을 잡을 수 있습니다. 편집기를 통해 어떤 타입을 추론

타입 선언은 할당되는 값이 해당 인터페이스를 만족하는지 검사합니다. 타입 단언은 강제로 타입을 지정했으니 타입 체커에게 오류를 무시하라고 하는 것입니다.타입 속성을 추가할 때도 마찬가지 입니다.Person을 원했지만 경과는 {name: string;}\[]...단언문을

자바(타입)스트립트에서는 함수표현식과 함수문장을 다르게 인식합니다.타입 스크립트에서는 함수 표현식을 사용하는 것이 좋습니다. 함수의 매개변수부터 반환값까지 전체를 함수 타입으로 선언하여 함수 표현식에 재사용할 수 있다는 장점이 있기 때문입니다.example반복되는 함수

아이템13) 타입과 인터페이스의 차이점 알기 인터페이스나 타입에 추가 속성과 함께 할당한다면 동일한 오류가 발생합니다. 인덱스 시그니처는 인터페이스와 타입에서 모두 사용할 수 있습니다. 인덱스 시그니처란? 인덱스 시그니쳐(Index Signature)는

중복되는 부분에 타입을 붙여 반복을 줄일 수 있습니다.아이템 12에 나왔던 시그니처를 명명된 타입으로 분리해낼 수 있습니다.인터페이스 확장을 통해서 반복을 제거할 수 있습니다. 일반적인 방벅은 아니지만 다음처럼 할 수있습니다.유니온 타입에 속성을 추가할 때 특히 유용합

인덱스 시그니처를 사용하여 유연하게 매핑을 표현할 수 있습니다.키의 이름: 키의 위치만 표시하는 용도입니다. 타입 체커에서는 사용하지 않기 때문에 무시할 수 있는 참고 정보라고 생각해도 됩니다.키의 타입: string 이나 number 또는 symbol의 조합이어야 하

아이템16) number 인덱스 시그니처보다는 Array, 튜플, ArrayLike를 사용하기 배열은 객체이므로 키는 숫자가 아니라 문자열입니다. 인덱스 시그니처로 사용된 number 타입은 버그를 잡기 위한 순수 타입 스크립트 코드입니다. 인덱스 시그니처에 num

타입스트립트가 타입을 추론할 수 있다면 타입 구문을 작성하지 않는 게 좋습니다.이상적인 경우 함수/메서드의 시그니처에는 타입 구문이 있지만, 함수 내의 지역 변수에는 타입 구문이 없습니다. 추론될 수 있는 경우라도 객체 리터럴과 함수 반환에는 타입 명시를 고려해야 합니

배열 탐색시 타입 가드를 사용해 타입을 좁힐 수 있습니다. 분기문 외에도 여러종류의 제어 흐름을 살펴보며 타입스크립트가 타입을 좁히는 과정을 이해해야 합니다.태그된/구별된 유니온과 사용자 정의 타입 가드를 사용하여 타입 좁히기 과정을 원활하게 만들 수 있습니다.속성을

콜백보다는 프로미스를 사용하는 게 코드 작성과 타입 추론 면에서 유리합니다.가능하면 프로미스를 생성하기보다는 async와 await을 사용하는 것이 좋습니다. 간결하고 직관적인 코드를 작성할 수 있고 모든 종류의 오류를 제거할 수 있습니다.어떤 함수가 프로미스를 반환한

유효한 상태와 무효한 상태를 둘 다 표현하는 타입은 혼란을 초래하기 쉽고 오류를 유발하게 됩니다.유효한 상태만 표현하는 타입을 지향해야 합니다. 코드가 길어지거나 표현하기 어렵지만 결국은 시간을 절약하고 고통을 줄일 수 있습니다.위처럼 작성하면 모호함을 완전히 제거할

보통 매개변수 타입은 반환 타입에 비해 범위가 넓은 경향이 있습니다. 선택 속성과 유니온 타입은 반환 타입보다 매개변수 타입에 더 일반적입니다. 매개변수와 반환 타입의 재사용을 위해서 기본 형태(반환 타입)와 느슨한 형태(매개변수 타입)를 도입하는 것이 좋습니다. 주석

'문자열을 남발하여 선언된' 코드를 피합시다. 모든 문자열을 할당할 수 있는 string 타입보다는 더 구체적인 타입을 사용하는 것이 좋습니다.변수의 범위를 보다 정확하게 표현하고 싶다면 string 타입보다는 문자열 리터럴 타입의 유니온을 사용하면 됩니다. 타입 체크

코드의 구석 구석까지 타입 안정성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 합니다.데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있기 때문에 데이터보다는 명세로부터 코드를 생성하는 것이 좋습니다.graphql를 사용할 때 apollo를

아이템 38) any 타입은 가능한 한 좁은 범위에서만 사용하기 의도치 않은 타입 안정성의 손실을 피하기 위해서 any의 사용 범위를 최소한으로 좁혀야 합니다. 함수의 반환 타입이 any인 경우 타입 안정성이 나빠집니다. 따라서 any타입을 반환하면 절대 안 됩니다

기본적으로 타입스크립트에서는 공변성을 갖고 있지만, 함수의 매개변수는 반공변성을 갖고 있습니다 반환값은 공변성을 띄지만, 매개변수는 반공명성을 띕니다. 공변성 반공변성 참조 https://www.zerocho.com/category/TypeScript/post

unknown은 any 대신 사용할 수 있는 안전한 타입입니다. 어떠한 값이 있지만 그 타입을 알지 못하는 경우라면 unknown을 사용하면 됩니다. 반환을 any로 하게되면, 작성중에는 오류가 발생하지 않고 런타임에서 오류가 발생합니다. 그리고 사용하는 곳마다 오류가

타입스크립트를 시스템 레벨로 설치하면 안 됩니다. 타입스크립트를 프로젝트의 devDependencies에 포함시키고 팀원 모두가 동일한 버전을 사용하도록 해야 합니다.@types 의존성은 dependencies가 아니라 devDependecies에 포함시켜야 합니다.

아이템 49) 콜백에서 this에 대한 타입 제공하기 this 바인딩이 동작하는 원리를 이해해야합니다. 콜백 함수에서 this를 사용해야 한다면, 타입 정보를 명시해야 합니다. 아이템 50) 오버로딩 타입보다는 조건부 타입을 사용하기 오버로드 타입보다는 조건부 타

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