외부로 드러나는 타입 정의는 간단하지만 내부 로직이 복잡해서 안전한 타입으로 구현하기 어려운 경우 이상적: 함수의 모든 부분을 안전한 타입으로 구현 단, 예외 상황까지 고려하며 타입 정보를 힘들게 구성할 필요는 없다. 함수 내부에는 타입 단언을 사용하고 함수 외부로 드러나는 타입 정의를 정확히 명시하는 정도로 끝내는 것이 나음 프로젝트 전반에 위험한 타입 단언문이 드러나 있는 것보다, 제대로 타입이 정의된 함수 안으로 타입 단언문을 감추는 것이 더 좋은 설계 declare function cacheLast(fn: T): T; declare function shallowEqual(a: any, b: any): boolean; function cacheLast(fn: T): T { let lastArgs: ..
타입스크립트는 타입을 추론할 때 단순히 값만 고려하지 않음 값이 존재하는 곳의 문맥까지 고려 문맥을 고려해 타입을 추론할 때 이상한 결과가 나올 수도 자바스크립트와 타입스크립트의 차이 자바스크립트 function setLanguage(language: string) { /* ... */ } setLanguage('JavaScript'); // OK let language = 'JavaScript'; setLanguage(language); // OK 타입스크립트 inline 형태에서 TS는 함수 선언을 통해 매개변수가 Language타입이어야 함을 앎 값을 변수로 분리하면, TS는 할당 시점에 타입을 추론 type Language = 'JavaScript' | 'TypeScript' | 'Python';..
콜백 지옥의 문제점 실행의 순서는 코드의 순서와 반대 콜백이 중첩된 코드는 직관적으로 이해하기 어려움 요청들을 병렬로 실행하거나 오류 상황을 해결하기 어려움 fetchURL(url1, function(response1) { fetchURL(url2, function(response2) { fetchURL(url3, function(response3) { // ... console.log(1); }); console.log(2); }); console.log(3); }); console.log(4); //출력: 4 3 2 1 Promise 콜백 지옥을 해결하기 위해 도입 (미래에 가능해질 어떤 것) 실행의 순서는 코드의 순서와 동일 오류 처리, Promise.all과 같은 고급 기법 사용에 용이 const..
DRY: 같은 코드를 반복하지 마라 타입에서 중복이 더 흔한 이유 중 하나는 공유된 패턴을 제거하는 메커니즘이 기존 코드에서 하던 것과 비교해 덜 익숙하기 때문 반복을 줄이는 가장 간단한 방법 → 타입에 이름을 붙이는 것 중복된 타입은 종종 문법에 의해서 가려지기도 함 확장해서 반복 제거하는 방법 두 인터페이스가 필드의 부분 집합을 공유한다면, 공통 필드만 골라서 기반 클래스로 분리 가능 interface Person { firstNmae: string; lastName: sring; } interface PersonWithBirthDate extends Person { birth: Date; } interface PersonWithAge extends Person { age: number; } 이미 존..
타입스크립트에서 명명된 타입(named type)을 정의하는 방법은 두가지 타입 사용 type TState = { name: string; capital: string; } 인터페이스 사용 interface IState { name: string; capital: string; } +) 인터페이스 대신 클래스를 사용할 수 있지만, 클래스는 값으로도 쓰일 수 있는 자바스크립트 런타임 개념 대부분의 경우 타입과 인터페이스 모두 사용 가능 같은 상황에서는 동일한 방법으로 명명된 타입을 정의해 일관성을 유지해야 인터페이스 선언과 타입선언의 비슷한 점 명명된 타입은 둘 다 상태에는 차이가 X 추가 속성과 함께 할당한다면 동일한 오류가 발생할 것 const wyoming: TState = { name: "wyomi..
팀바팀은 github action을 이용해 프론트엔드 PR시 테스트를 잘 통과하는지 자동으로 테스트하고 있다. 또한, 추후에 Build시 빌드가 잘 되는지 자동으로 테스트할 예정이다. 테스트 자동화를 하면 여러명이 하나의 프로젝트를 같이 진행하는 만큼 나의 코드가 기존의 테스트에 영향을 주는지 사람이 직접 확인하지 않아도 쉽게 확인할 수 있다. 테스트가 통과하지 못한다면 merge를 하지 못하게 막아 merge시 안전성을 높일 수 있다. Github Action을 이용한 테스트 자동화 github workflows의 하위에 다음과 같은 파일을 넣는다. 확장자는 .yml이다. 자세한 내용은 아래 주석으로 작성했다. name: frontend-ci //액션의 이름 on: pull_request: //PR 요..
