JS & TS/Typescript

이전에 [ 분배 법칙에서의 타입 추론 컨텍스트 ] 포스트를 통해 나는 타입스크립트에서 분배 법칙이 일어날 때 그 컨텍스트가 유지된다는 것을 확인했고, 이를 기반으로 복잡한 조건부 타입에서도 원하는 타입 추론을 이끌어낼 수 있다는 점을 알게 되었다. 그런데 Caro-Kann 다음 버전의 persist migration을 처리하기 위한 MigrationPipe 타입을 설계하는 중에 한 가지 이상한 현상을 발견하게 되었다. 내가 만든 상태 관리 라이브러리 Caro-Kann은 persist 버전 migration을 아래와 같이 처리하고 있다. persist 버전이 몇 개 없다면 괜찮겠지만, 버전이 조금만 늘어나도 정확한 migration을 담보할 수 없는 상황이다. 게다가 이전 버전들이 어떤 구조로 되어있는지 ..

프론트엔드 개발을 하다 보면 컴포넌트의 props로 number 타입을 받을 때가 많다. 하지만 단순히 number 타입만 지정하면 값의 범위를 제한할 수 없다는 점이 아쉽다. 예를 들어, 페이지네이션의 currentPage는 1 이상의 값만 허용해야 하고, 슬라이더의 value는 최소/최대 값을 벗어나지 않아야 한다. 이를 보완하기 위해 TypeScript의 타입 시스템을 활용해 특정 범위 내의 숫자만 허용하는 유틸리티 타입 IsInRange를 만들어야겠다고 생각했다. 처음에는 아래와 같이 재귀적으로 타입을 호출하며 범위 내에 특정 숫자 리터럴 타입이 존재하는지를 검사했다. 이러한 방법은 논리적으로 문제가 없지만, 실제로는 몇 가지 하자가 존재한다. 우선 범위가 1000이 넘어가버리면 콜스택이 폭발해버..

유니온 타입의 분배 법칙TypeScript에서 제네릭 타입의 자리에 유니온 타입이 오게 되면, 타입 연산 ─ 주로 조건부 타입, 맵드 타입, 템플릿 리터럴 타입, 스프레드 연산 등 ─ 과 결합될 때 분배 법칙(distributive law)이 적용된다. 이는 제네릭 타입이 유니온 타입을 받을 경우, 개별 요소에 대해 조건부 타입이 각각 평가된다는 의미이다. 예를 들어, 다음과 같은 조건부 타입을 고려해 보자. 위 코드에서 T에 "hello" | 42가 들어가면, 단순히 string과 비교하는 것이 아니라 각 요소가 개별적으로 평가된다. 이를 naked 타입이라고도 부른다.type Example = T extends string ? number : boolean;type Result = Example;//..

TypeScript에서 두 개의 타입이 겉보기에는 동일하지만, 실제로 비교하면 다르게 평가되는 경우가 있다. 예를 들어, 다음 두 타입을 비교해보자.type A = { x: string, y: string };type B = { x: string } & { y: string }; 두 타입 A와 B는 직관적으로 같아 보인다. 하지만 TypeScript는 { x: string, y: string }과 { x: string } & { y: string }을 동일한 타입으로 간주하지 않는다. 이를 확인하기 위해 두 타입이 완전히 동일한지 판별하는 유틸리티 타입 IsEqual을 만들어보자.type IsEqual = (() => T extends X ? 1 : 2) extends (() => T extends Y..

언젠가 동생이 내게 이런 질문을 한 적이 있다. "형은 어떨 때 type을 쓰고 어떨 때 interface를 써?" 그리고 나는 대부분의 경우 type을 쓴다고 대답했다. 이유는 간단한데, 선언 병합 외에 interface가 더 나은 점을 찾을 수 없었기 때문이었다. 확실히 '기능'만 놓고 본다면 굳이 interface를 쓸 이유가 없어보이기는 한다. 하지만 동생이 다시 한 번 질문을 해온다면 지금의 나는 이렇게 대답할 것 같다. 인터페이스라는 표현을 가장 자주 접하는 건 아마도 API지 않을까 싶다. 특히 나는 웹 개발자라 그런가 REST API가 제일 먼저 떠오르는데, 여기서는 "독립되고 관계가 없는 시스템이 접촉하거나 통신이 일어나는 부분"을 인터페이스라고 부른다. 웹서버와 백엔드 서버는 독립되고 ..

객체지향 프로그래밍(OOP)에서 추상 클래스와 인터페이스는 코드의 구조를 명확히 하고 재사용성을 높이기 위해 사용된다. 두 개념 모두 클래스 간의 일관성을 유지하고, 개발자들이 특정 규칙을 따르도록 강제하는 데 사용되지만 그 역할과 사용 목적에는 분명한 차이가 있다. abstract class객체지향에서 추상 클래스는 인스턴스화할 수 없으며 상속만 가능하다. 즉, new 예약어를 통해 추상 클래스의 객체를 정의할 수 없는 것이다. 추상 클래스는 공통적인 속성과 동작을 정의하면서도, 일부 메서드는 구현하지 않아 자식 클래스에서 구현하도록 강제한다. 이를 통해 공통 기능을 공유하면서도 유연하게 세부 동작을 다르게 가져갈 수 있다. 또한 속성(상태)를 포함할 수 있기에 클래스 간 기본 데이터를 제공할 수 있다..

요즘 프론트 과제를 진행하면서 caro-kann 3 버전을 적극적으로 사용하고 있다. 여러 기능을 미들웨어로 분리하여 번들 크기도 700b대로 줄였고, zustand∙useReducer∙useState 문법을 취사 선택할 수 있다는 점이 나에게는 다른 라이브러리 못지 않은 장점으로 여겨지기 때문이다.며칠 전에도 caro-kann에 reducer와 persist 미들웨어를 결합하여 세션 종료에도 버티는 장바구니 기능을 만들고 있었다. 보통 장바구니에는 product를 보관하고, 장바구니 페이지에서는 보관하고 있는 product를 모두 랜더링한다. 그런 만큼 전역 장바구니 상태는 배열의 형태를 띄는 게 일반적이다.export const useCartStore = create( reducer((state, ..

아래는 전역 상태 관리 라이브러리 Caro-kann의 persist 미들웨어가 사용하는 유틸리티 함수의 타입이다. 각각의 함수는 모두 동일한 파라미터인 storageKey와 storageType을 필요로 하고 있다. GetStorage와 SetStorage는 그 이름 덕분에 무슨 동작을 하는지 쉽게 알 수 있다. 하지만 ExecMigration 타입은 정확히 뭘 하는지, GetStorage와 SetStorage 타입과는 무슨 관련이 있는지 알기 어렵다. 모르는 개발자가 처음 이 타입들을 본다면 ExecMigration와 나머지 두 타입이 관계가 없다고 생각할 지도 모르겠다.type GetStorage: (props: { storageKey: string; storageType: keyof Storag..

라이브러리를 개발하다보면 특정 객체 타입의 프로퍼티는 유지하되, 일부 프로퍼티 값의 타입을 바꿔줘야 하는 경우가 생긴다. 특히 오버라이드 패턴을 사용해 메서드의 일부 동작이 변경되는 경우가 여기 포함된다. 타입스크립트에서는 주로 Omit Pick Partial 등의 유틸리티 타입을 사용해 이런 오버라이드를 구현한다.type ReducerStore = Omit, "setStore"> & { setStore: Dispatcher }하지만 Omit과 & 연산자 등을 사용해 타입을 선언하다보니 이 타입이 뭘 하고 있는 건지 한 눈에 알기가 어렵다. 나는 이러한 문제를 해결하기 위해 ReplacePropertyValue라는 유틸리티 타입을 라이브러리에 도입했다.type ReplacePropertyValue = O..

Caro-Kann 2.2 버전을 작성하고 있는데 한 가지 문제에 봉착했다. 전역 상태를 스토리지에 저장할 때는 반드시 한 곳을 지정해야 한다. 가령 로컬 스토리지에 저장한다면 세션 스토리지는 지정할 수 없어야 하고, 그 반대도 성립해야 하는 것이다.type StorageConfig = { local: "???"; session: "???" };이를 런타임에서 잡아내는 것은 쉽지만, 나는 타입스크립트를 사용해서 미리 타입 에러를 던지고 싶었다. 이 문제를 해결하려면 StorageConfig 타입을 정의할 때 두 필드 중 하나가 정해지면, 다른 하나는 허용하지 않도록 강제해야 한다. 유니온 타입과 never를 사용하면 이 요구사항을 만족할 수 있다.예를 들어, local이 정의되면 session은 never..

자바스크립트에서 템플릿 리터럴이란 변수를 문자열 내에 삽입할 수 있도록 하는 문법을 지칭한다. 타입스크립트에서도 이와 유사하게 템플릿 리터럴 타입이 존재한다. 기존의 리터럴 타입 및 유니언 타입을 변수처럼 사용하여 새로운 문자열 타입을 구성하는 방식이다. 이를 통해 문자열을 결합하거나 변형한 새로운 타입을 정의할 수 있으며, 타입스크립트의 강력한 타입 시스템과 결합하여 타입 안전성을 유지하면서도 유연하게 문자열 기반 타입을 다룰 수 있다.// 일반적인 템플릿 리터럴 타입의 사용법type VerticalAlignment = "top" | "middle" | "bottom";type HorizontalAlignment = "left" | "center" | "right";// type Alignment =/..

조건부 타입타입스크립트는 특정 조건에 따라 타입을 다르게 정의할 수 있도록 하는 '조건부 타입'을 지원한다. 자바스크립트의 삼항 연산자와 유사하게 타입 수준에서 조건을 평가하며, 그 결과에 따라 다른 타입을 선택할 수 있다. infer 키워드와 함께 사용하면 함수나 배열, 객체 등에서 특정 타입을 추출하거나 분해하는 데 도움이 된다.아래의 예시 타입은 배열을 인자로 받아서 해당 배열의 첫번째 아이템을 리턴하는 함수의 타입을 조건부 타입과 infer 키워드를 사용해 설계한 것이다. type FirstElement = (arr: T) => T extends [infer First, ...any[]] ? First : never;const getFirstElement: FirstElement = (arr) =..