타입스크립트

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의 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..

나는 꽤 오래 전부터 타입스크립트를 사용해 특정한 컴포넌트만을 걸러낼 수 있을지 궁금했다. 만약 이게 가능하다면 특정한 컴포넌트만을 children으로 받게 만들 수 있어 프로젝트의 전체적인 구조가 단단해질 거라 생각했다. 실제로 특정 컴포넌트를 걸러내기 위해서 나는 타입스크립트를 가지고 아주 다양한 시도를 해보았으며, 이 포스트는 수많은 삽질 속에서 알게 된 내용을 정리한 것이다. 컴포넌트를 이루는 타입들ReactNode나는 리액트 컴포넌트의 props로 children을 넘겨야 할 때, 항상 그 타입을 ReactNode로 선언했다. 습관 같은 것이었고 이에 대해 깊게 생각해본 적이 없었다. 결론부터 말하자면 ReactNode는 ReactElement를 포함하는 타입이다. 아래는 리액트에서 선언한 Re..

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

form 관리 라이브러리 sicilian을 만들면서 여러 타입을 작성하다가 아래와 같은 타입을 만들었다. 여기서 사용되는 Input 타입은 handleChange 함수의 인자로 들어오는 이벤트 객체의 타겟 이름이 특정한 K를 만족시키도록 강제한다. 아래의 스크린샷에서 확인할 수 있는 것처럼 이 타입의 추론은 두 개의 타입이 인터섹션되어있는 것으로 표시된다.export type Input = ChangeEvent & { target: { name: K; value: string } }; 그러다 지인의 추천으로 네이버 사내 기술 교류 행사에서 발표된 타입스크립트 세션 영상을 보게되었다. 다양한 테크닉을 배울 수 있는 좋은 기회였지만, 그 중에서 내 눈을 사로잡은 건 유틸리티 타입 Role의 동작이었다. Ro..

최근 라이브러리를 개발하는 과정에서 한 가지 타입 에러 때문에 꽤 오랫동안 골머리를 앓았다.function foo>(selector?: (state: T) => S) { const { getBar } = useContext(bar); if (selector) return selector(getBar()) else return getBar()}foo 함수는 selector라는 함수를 옵셔널하게 받고 있다. 이 selector 함수가 있으면 객체의 프로퍼티 일부만을 리턴하고, 없으면 객체 전체를 리턴하도록 만들었다. 나는 아규먼트 여부에 따라 타입스크립트가 그 리턴 값을 '정확하게' 추론해줄 거라 생각했다. 하지만 타입스크립트는 아규먼트 여부와 관계 없이 리턴 타입을 T | S로 추론했다.  내가 만들..