# effective-typescript

dev_jiminn

Item 27 : 함수형 기법과 라이브러리로 타입 흐름 유지하기 라이브러리 + TS를 조합해 사용할 시 효과적 → 타입 정보가 그대로 유지되며 타입 흐름이 지속적으로 전달되므로 cf) 루프를 구현하면 타입 체크에 대한 관리도 직접 해야 함 csv 데이터 파싱 예제(JS) vanilla JS : 절차형 프로그래밍으로 구현 가능 함수형 프로그래밍 선호 개발자 : reduce 사용 → 행 객체 생성 키와 값의 배열로 취합해 객체로 만드는 zipObject 함수 이용 → JS : 서드 파티 라이브러리 종속성을 추가할 때 신중해야 함 → 코드를 짧게 줄이는 데 시간이 많이 들 경우, 사용 지양할 것 → TS : 서드파티 라이브러리 사용이 무조건 유리 → 타입 정보를 참고해 작업할 수 있으므로, 서드파티 라이브러리 기반으로 변형 시 시간

dev_jiminn

Item 26 : 타입 추론에 문맥이 어떻게 사용되는지 이해하기 TS가 타입을 추론하는 방식 : 값 고려 → 값이 존재하는 곳의 문맥 고려 문맥을 고려해 타입 추론 시 종종 이상한 결과 발생 → 타입 추론에 문맥이 어떻게 사용되는지 이해함으로써 대처 동일한 두 문장 인라인 형태에서 TS는 함수 선언을 통해 매개변수가 Language 타입임을 알고 있음 이 값을 변수로 분리해내면, TS는 할당 시점에 타입 추론 : string으로 추론 → Language 타입으로 할당이 불가능하므로 오류 발생 해결 방법 타입 선언에서 language의 가능한 값을 제한 language를 상수로 만드는 방법 문맥으로부터 값을 분리함 → 근본적 문제 발생의 원인이 됨 튜플 사용 시 주의점 > 해당 문제의 발생 원인 : const는 얕게(shallow

dev_jiminn

Item 25 : 비동기 코드에는 콜백 대신 async 함수 사용하기 과거 JS : 콜백 지옥을 필연적으로 마주할 수 밖에 없는 상황 → ES2015 : 콜백 지옥 개선을 위해 프로미스(promise) 개념 도입 → ES2017 : async & await 키워드 도입 await : 각각의 프로미스가 처리(resolve)될 때까지 fetchPages 함수 실행 멈춤 async 함수 내에서 await 중인 프로미스가 거절(reject)되면 예외 던짐 → 일반적인 try/catch 구문 사용 가능 ES5- 버전 대상으로 할 때의 TS 컴파일러 : async & await가 동작하도록 정교한 변환 수행 → TS는 런타임에 관계 없이 async & await 사용 가능 콜백보다 프로미스나 async/await를 사용해야

dev_jiminn

Item 24 : 일관성 있는 별칭 사용하기 borough.location 배열에 loc 별칭(alias) 생성 예제 → 별칭의 값 변경 시 원래 속성값에서도 변경 별칭 남발 시 제어 흐름 분석에 어려움 발생 다각형을 표현하는 자료구조 → 다각형의 기하학적 구성 : exterior와 holes로 구성 → bbox : 최적화 속성(옵션) : 잘 동작(타입 체커 통과), 반복되는 부분 존재 → 중복을 줄이기 위해 임시 변수를 뽑아내는 방법 : 편집기에서 오류로 표시됨 → polygon.bbox를 별도의 box로 별칭했고, 제어 흐름 분석을 방해했으므로 : 오류 발생 원인 : 속성 체크는 polygon.bbox 타입 정제 O, box 타입 정제 X → 별칭을 일관성 있게 사용한다는 원칙 지킬 시 방지 가능 Best case : 속성 체크에 box를 사용하도록

dev_jiminn

Item 23 : 한꺼번에 객체 생성하기 Item 20: “변수의 값은 바뀔 수 있지만, 그 타입은 보통 바뀌지 않는다.” → JS 패턴을 TS로 모델링하는 것이 쉬워짐 → 여러 속성을 포함해 한꺼번에 생성하는 것이 타입 추론에 유리 (worse. 객체 생성 시 속성을 하나씩 추가하는 방식) 첫 줄의 pt 타입 : {}값을 기준으로 추론되므로 → 존재하지 않는 속성의 추가 불가능 Point 인터페이스 추가 시 오류 변경 내용 sol. 객체를 한 번에 정의 객체를 반드시 제각각 나눠 만들어야 하는 경우, 타입 단언문(as) 사용해 타입 체커 통과 작은 객체를 조합해 큰 객체를 만드는 경우 Worst case : 여러 단계를 거치는 경우 Best case : **객체 전개 연산자(…)

defaultkyle

아래 작성된 글은 이펙티브 타입스크립트를 1회독하면서 이해한 내용을 바탕으로 작성된 글입니다. 매 주 1회씩 1장씩 정리합니다. 01 타입스크립트와 자바스크립트의 관계 타입스크립트는 사용 방식 면에서 독특한 언어입니다. 최종적으로 자바스크립트로 컴파일 되며, 타입스크립트가 아닌 자바스크립트로 실행됩니다. 다른 언어들과 다르게 타입 시스템도 독특합니다. > 💿 '타입스크립트는 타입이 정의된 자바스크립트의 상위 집합이다'라는 말을 자주 들었을 것입니다. 모든 자바스크립트가 타입스크립트이다 [O] 모든 타입스크립트가 자바스크립트이다 [X] 위의 코드에서 stete 라고 작성되어 있는 프로퍼티를 타입 선언으로 타입 체크를 통해, 런타임 동작 이전에 오류를 체크하여 미래에 발생할 잠재적 문제를 방지할 수 있습니다. → 따라서, 타입스크립트 프로그램은 자바스크립트 프로그램과 타입 체커를 통과한 타입스크립트 프로그램을 포함하

kandy1002

Effective Typescript에 대한 스터디 진행 내용을 요약한 것입니다. 함수 표현식에 타입 적용하기 TS에서 함수를 표현하는 방식은 두 가지가 있다. 함수 선언문과 함수 표현식이 그것인데, 아래 코드를 통해 둘의 차이를 살펴보자. 위 식에서 아래 두 개는 함수 표현식, 맨 위는 함수 선언문에 해당된다. TS에서는 함수 표현식을 사용하기를 권장하는데, 그 이유는 아래와 같다. > TS에서는 함수 표현식을 사용하기를 권장하고 있습니다. 함수의 매개변수부터 반환 값까지 전체를 함수 타입으로 선언하여 함수 표현식을 재사용할 수 있다는 장점이 있기 때문입니다. 즉 위와 같이 함수 표현식 포맷으로 함수 타입을 지정해두면 언제 어디서나 타입을 재사용할 수 있다는 얘기다! 함수 표현식은 다음과 같은 상황에서 유용하게 사용될 수 있다. 위의 상황처럼 fetching 함수를 선언할 때 직접

seobbang

📌 함수 표현식에 타입 적용하기 함수 '문장'과 함수 '표현식' 자바스크립트에서는 함수 '문장'과 함수 '표현식'을 다르게 인식한다. 함수 문장 함수 표현식 ▶ 타입스크립트에서는 함수 표현식을 사용하는 것이 좋다! 함수의 매개변수부터 반환값까지 전체를 함수타입으로 선언하여 함수 표현식에 재사용할 수 있기 때문 공통 함수 시그니처 >함수 시그니처란? 함수 타입 문법을 의미한다. 라이브러리는 공통 함수 시그니처를 타입으로 제공하기도 한다. ex) 리액트는 매개변수에 명시하는 MouseEvent 타입 대신에 함수 전체에 적용할 수 있는 MouseEventHandler 타입을 제공한다. 시그니처가 일치하는 다른 함수가 있을 때, 함수 표현식에 타입 적용하기 ex) 웹브라우저 fetch에 관련된 예시를 보자 fetch : 특정 리소스에 HTTP 요청을 보내고, response.json()

seobbang

📌 타입 단언보다는 타입 선언을 사용하기 타입 단언과 타입 선언 타입을 부여하는 방법 두 가지이다. 타입 선언 : 그 값이 선언된 타입임을 명시 타입 단언 : 타입스크립트가 추론한 타입이 있더라도 Person(단언한) 타입으로 간주 타입 선언 -> 할당되는 값이 해당 인터페이스를 만족하는지 검사 타입 단언 -> 강제로 타입을 지정해서 타입 체커가 오류를 무시하도록 만듬 ✅ 결론 : 타입 단언 보다는 타입 선언을 사용하자! > ➕ 알아가기 원래 타입 단언의 문법은 const bob = {}이다. 그러나 `이 .tsx`파일에서 컴포넌트 태그로 인식되기 때문에 현재는 잘 쓰이지 않는다. 타입 단언이 꼭 필요한 경우 타입 체커가 추론한 타입보다 우리가 판단하는 타입이 더 정확할 때 ex1) DOM 엘리먼트 -> <span style="text-decoration: under

soy0830

타입스크립트로 마이그레이션하기 아이템 58 모던 자바스크립트로 작성하기 ECMAScript 모듈과 ES2015 클래스 기능을 사용해 자바스크립트 코드를 작성해야한다. ECMAScript 모듈 사용 프로토 타입 대신 클래스 let/const 사용 for(;;;) 대신 for-of 또는 배열 메서드(forEach) 함수 표현식보다 화살표 함수 단축 객체표현과 구조분해할당 async/await 연관 배열에 객체 대신 Map 과 Set 타입스크립트에 ‘use strict’ 넣지 않기 아이템 59 타입스크립트 도입 전에 @ts-check와 JSDoc으로 시험해보기 파일 상단에 //@ts-check를 사용하여 타입스크립트 전환시 어떤 문제가 발생하는지 미리 시험해볼 수 있다. 하지만 매우 느슨하게 체크하기에 주의해야한다. @ts-check를 사용하면 다음과 같은 오류를 찾아낼 수 있다. 타입 불

soy0830

코드를 작성하고 실행하기 아이템 53 타입스크립트 기능보다는 ECMAScript 기능을 사용하기 타입스크립트는 타입 기능만 발전시킨다. 열거형(enum) 대신 리터럴 타입의 유니온 사용하기 매개변수 속성 대신 일반 속성 사용하기 ES2015의 import/export 모듈 사용하기 데코레이터(ex. logged 애너테이션) 사용하지 않기 아이템 54 객체를 순회하는 노하우 처음에는 k의 타입은 string으로 추론되었지만 keyof를 사용해 키 타입을 한정지을 수 있어 k의 타입은 "a" | "b" | "c" 가 되었다. 하지만 ABC에 존재하지 않는 이외의 속성들(예를 들어 d) 이 할당될 수도 있고 → 객체의 키와 값을 순회하기 위해서는 object.entries 사용 아이템 55 DOM 계층 구조 이해하기 타입스크립트는 DOM 계층 구조 파악하기 용이하다. ![Untit

soy0830

타입 선언과 @types 라이브러리 의존성 관리를 위해서는 타입스크립트에서 의존성이 어떻게 동작하는지 이해해야한다. 아이템 45 devDepndencies 에 typescript와 @types 추가하기 npm은 각 라이브러리를 의존성에 따라 package.json 파일 안에서 3가지로 구분해서 관리한다. dependencies : 현재 프로젝트를 실행하는데 필수적인 라이브러리 devDepndencies : 현재 프로젝트를 개발하고 테스트하는데 사용되지만, 런타임에서는 필요없는 라이브러리 peerDepndencies : 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리 → 타입스크립트는 devDepndencies 에 속한다. 아이템 46 타입 선언과 관련된 세 가지 버전 이해하기 타입스크립트를 사용할 때에는 1️⃣ 라이브러리의 버전 2️⃣ 타입선언(@types) 의 버전 3️⃣ 타입스크립트의 버전

seobbang

📌 편집기를 사용하여 타입 시스템 탐색하기 타입스크립트의 타입 추론 내가 의도한 타입과 타입스크립트가 추론한 타입이 다를 수 있으니 특정 시점에 타입스크립트가 값의 타입을 어떻게 이해하고 있는지 살펴보며 필요시 타입을 명시하자. 편집기상의 타입 오류 살펴보기 에러 메시지 해석 자바스크립트에서 typeof null : "object"이므로 elOrId는 여전히 null일 수 있는 것! HTMLElement를 반환해야하는 함수이기 때문에 에러가 남. --> typeof null이 object임을 몰랐을 때를 가정한다면, 편집기상의 오류를 잘 참고하고, 살펴봐야 하는 이유! 언어에서 제공하는 라이브러리의 타입 선언 정의 적극 활용하기 타입스크립트가 동작을 어떻게 모델링하는지 알기 위해 편집기가 제공하는 Go to Definition(정의로 이

ghenmaru

1. TS와 JS의 관계 타입스크립트 : 자바스크립트 + 타입 -> 자바스크립트의 상위 호환 자바스크립트로 컴파일되며, 실행 역시 자바스크립트로 이루어짐 자바스크립트 런타임 동작을 모델링하는 타입시스템을 가짐 타입스크립트는 초깃값으로부터 타입을 추론한다 **하지만 타입 체커를 통과한다고 하더라도 런타임 오류가 발생할 수 있다 ! ** 2. 타입스크립트 설정 이해하기 타입스크립트 설정은 tsconfig.json 파일을 사용하며, 루트 디렉토리에 위치 noImplicitAny : 변수들이 미리 정의된 타입을 가져야 하는지 체크 strickNullChecks : null과 undefined가 모든 타입에서 허용되는지 체크 3. 컴파일과 타입 체크는 독립적이다 [타입스크립트 컴파일러의 역할] **1. 최신 타입스크립트/자바스크립트를 구버전의 자바스크립트로 트랜스파일 타입 체크 ** 타입 오류가 있어도 컴파일이 된다 컴파일과 타입체크가 독립적

soy0830

타입스크립트는 프로그램의 일부분에만 타입 시스템을 적용할 수 있다는 특성 덕분에 점진적으로 자바스크립트를 타입스크립트로 전환할 수 있다. any가 남용되면 타입 체크의 의미를 퇴색시키기에 적절한 위치에서 사용해야한다. 아이템 38 any 타입은 가능한 한 좁은 범위에서만 사용하기 → f1과 같이 x에 any타입을 부여하게 되면 함수의 리턴값까지 any를 반환하기 때문에 프로젝트에 전반적으로 영향을 끼치게 된다. 만약 타입 오류를 제거하고 싶다면 @ts-ignore을 사용하면 된다. → 다른 속성들(a,b) 역시 타입체크가 되지 않는다. 아이템 39 any를 구체적으로 변형해서 사용하기 any 타입 : 모든 숫자, 문자열, 배열, 객체, 정규식, 함수, 클래스, DOM 엘리먼트, null , undefined → any를 더 구체적으로 표현할 수 있는 타입을 사용하자! 함수의 매개변수가 객체이긴 하지만 값을 알 수 없다

soy0830

타입 추론 타입스크립트는 타입 추론을 적극적으로 수행한다. 아이템 19 추론 가능한 타입을 사용해 장황한 코드 방지하기 타입 추론이 된다면 명시적 타입 구문은 필요하지 않다. 비구조화 할당을 통해 타입이 추론된다면 명시적 타입 선언은 불필요하다. 객체 리터럴 정의할 때 타입을 명시하면 잉여 속성 체크로 속성 오타 등 언어서비스를 사용할 수 있고, 변수가 할당되는 시점에 오류를 표시해준다. 함수의 반환에도 타입을 명시하여 오류를 방지하면 좋다. 아이템 20 다른 타입에는 다른 변수 사용하기 “변수의 값은 바뀔 수 있지만 보통 그 타입은 바뀌지 않기”때문에 타입이 다르면 별도의 변수를 생성한다. const로 변수를 선언하면 코드가 간결해지고, 타입체커가 타입을 추론하기에도 좋다. 아이템 21 타입 넓히기 런타임에는 모든 변수는 유일한 값을 가진다. 그러나 타입스크립트가 작성된 코드를 체크하는 정적 분석

soy0830

타입스크립트의 타입 시스템 아이템 6 편집기를 사용하여 타입 시스템 탐색하기 타입스크립트를 설치하면, 다음 두가지를 실행할 수 있다. 타입스크립트 컴파일러(tsc) 단독으로 실행할 수 있는 타입스크립트 서버(tsserver) - 편집기에서 사용하는 언어 서비스 제공 편집기를 통해 특정 시점의 추론된 타입 값을 알 수 있다. 아이템 7 타입이 값들의 집합이라고 생각하기 타입 : 할당 가능한 값들의 집합, 범위 유닛(unit)타입, 리터럴(literal) 타입 : 한가지의 타입만 포함 유니온(union) : 값 집합들의 합집합 타입 연산자는 인터페이스의 속성이 아닌, 값의 집합(타입의 범위)에 적용된다. 그리고 추가적인 속성을 가지는 값도 여전히 그 타입에 속한다. Person와 LifeSpan의 인터섹션은 Person의 범위와 LifeSpan의 범위의 인터섹션이다. 그래서 Person과 Lifespan을 둘 다 가지는 값은

seobbang

먼저, 타입스크립트가 다른 언어들과 다른점은? 파이썬, 루비 : 인터프리터로 실행됨 자바, C : 저수준 언어로 컴파일됨 타입스크립트는 또 다른 고수준 언어인 JS로 컴파일 되고, JS로 실행되는 언어 📌 TypeScript와 JavaScript의 관계 TypeScript는 JavaScript의 '상위집합' .js 파일에 있는 코드는 이미 TS라고 할 수 있다! 반대로, TS는 별도의 문법이 있기 때문에 일반적으로 유효한 JS가 아니다. 타입 추론 : 타입 체커로 잠재적 문제점 찾아내기. TS는 JS 런타임 동작을 모델링하는 타입 시스템을 가지고 있음. Typescript의 목표 : 런타임에 오류를 발생시킬 코드를 미리 찾아내는 것. (❗ 그러나 모든 오류를 잡아내는 것은 아님) 오류 뿐만 아니

soy0830

타입스크립트 알아보기 라이브러리 의존성 관리를 위해서는 타입스크립트에서 의존성이 어떻게 동작하는지 이해해야한다. 아이템 1 타입스크립트와 자바스크립트의 관계 이해하기 타입스크립트는 문법적으로 자바스크립트의 상위 집합이다. 그러나 문법의 유효성과 동작의 이슈는 독립적인 문제이다. → 문법의 오류가 없어도 타입 체커에게 지적당할 수 있다. 모든 자바스크립트는 타입스크립트이지만, 모든 타입스크립트는 자바스크립트가 아니다. 타입스크립트는 코드의 동작과 의도가 다른 부분을 찾아낸다. 타입스크립트는 자바스크립트의 런타임 동작을 모델링한다. 타입스크립트는 모델링 뿐만 아니라 추가적인 타입 체크를 한다. 하지만 타입 체크를 해도 런타임 오류가 발생하는 경우가 있다. 타입 시스템이 정적 타입의 정확성을 보장하지는 않는다. ( 이를 원하면 다른 언어를 사용해야한다. ) → 그러면 ts를 왜 쓰는걸까? 코드의 타입 오류를 체크하고( p.12) 의도와 다르게

s2ksh77

인프런 강의 https://www.inflearn.com/course/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C-%ED%83%80%EC%9E%85%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%8A%A4%ED%84%B0%EB%94%94 강의와 함께 스터디하면서 훑어보기 한 내용을 정리해보려고 한다. Item 1 타입스크립트와 자바스크립트의 관계 이해하기 TypeScript와 JavaScript 관계 이해하기 TypeScript는 JavaScript의 슈퍼셋이며, JavaScript와 호환됩니다. 따라서 JavaScript의 기본 개념과 구조를 잘 이해해야 TypeScript를 잘 다룰 수 있습니다. 타입시스템의 목표