JS & TS

이 글의 제목은 ‘자바스크립트에서의 멀티패러다임 프로그래밍’이지만, 우선은 영어에 대해 이야기해보자. 다소 뜬금없다고 느낄 수도 있겠지만, 다 이유가 있다.아주 오래전, 국제 외교의 언어는 프랑스어였다. 왕실 간의 외교문서와 고위 외교관의 대화는 프랑스어로 쓰이는 것이 관례였다. 하지만 지금은 전 세계 어디서든 영어가 표준 언어처럼 쓰인다. 그 배경에는 분명히 영국의 제국주의와 미국의 군사력, 경제력, 그리고 인터넷과 미디어 산업의 힘이 있다.하지만 나는 거기에 더해 영어 자체의 문법적 유연함도 중요한 역할을 했다고 생각한다. 영어는 문법이 다소 틀려도 의미가 통하고, 억양이나 맥락으로도 충분히 의사소통이 가능하다. 완벽하지 않아도 전달되는 언어, 이것이 영어가 세계적으로 퍼질 수 있었던 이유 중 하나였..

Iteration Protocol이터레이션 프로토콜은 자바스크립트에서 데이터를 순회하기 위한 표준화된 규약으로, 컬렉션(배열, 문자열 등)을 순회 가능한 형태로 정의한다. 이 프로토콜은 두 가지로 나뉘며, 하나는 이터러블 프로토콜(Iterable Protocol), 다른 하나는 이터레이터 프로토콜(Iterator Protocol)이다. 어떤 객체가 Symbol.iterator 메서드를 가지고 있고 이를 호출한 결과로 이터레이터(iterator)가 반환된다면, 그 객체는 이터러블하다고 말할 수 있다. 이터러블한 객체는 for...of 문, 전개 연산자(...), 비구조화 할당 등에서 사용할 수 있으며, 자바스크립트의 다양한 문법이 이 프로토콜 위에 구성되어 있다.반면, 이터레이터는 next() 메서드를 가..

자바스크립트를 사용하다 보면 await 없이 비동기 함수를 호출하거나, .then(), .catch() 같은 후속 처리 없이 Promise를 생성하는 코드를 종종 보게 된다. 겉보기에 문제는 없어 보이지만, 이런 방식은 비동기 작업이 제대로 실행되지 않거나 중간에 무시될 위험을 내포하고 있다. 후속 처리를 붙이지 않으면 해당 Promise는 단지 생성만 된 채 아무도 추적하지 않는 상태로 남기 때문이다. 이러한 상태를 Unhandled Promise 혹은 보호자 없이 방치된 아이와 같다고 하여 "비동기 고아(Orphan Promise)"라고 부른다. 문제가 발생하는 이유자바스크립트의 Promise는 비동기 작업의 결과를 나타내는 객체로, 생성 즉시 비동기 처리가 시작된다. 하지만 해당 Promise에 ...

기존 자바스크립트 사용자들은 객체의 속성 접근을 감지하거나 동작을 변경하기 위해 Object.defineProperty() 같은 방법을 사용했다. 그러나 여기에는 동적 속성 추가나 함수 호출과 같은 동작을 탐지하는 데 어려움이 있었다. 이를 해결하기 위해 자바스크립트에 Proxy 처리기가 도입되었다. 이 클래스는 get, set, apply 등 다양한 트랩(trap)을 제공하여 객체의 속성 접근, 값 변경, 삭제, 함수 호출 등의 동작을 자유롭게 제어할 수 있도록 한다. 아마도 이것이 Proxy 처리기에 대한 일반적인 인식일 것이다. 나도 큰 틀에서는 이러한 인식에 동의한다. 사소한 문제가 하나 있다면, 나는 '객체의 속성 접근을 감지하거나 동작을 변경'해야할 필요를 느끼지 못했다는 것이다. 더 자세히 ..

이전에 [ 분배 법칙에서의 타입 추론 컨텍스트 ] 포스트를 통해 나는 타입스크립트에서 분배 법칙이 일어날 때 그 컨텍스트가 유지된다는 것을 확인했고, 이를 기반으로 복잡한 조건부 타입에서도 원하는 타입 추론을 이끌어낼 수 있다는 점을 알게 되었다. 그런데 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..

렉시컬 스코프라는 단어를 처음 접했을 때, 나는 별 생각 없이 이것이 '렉시컬 환경에 따른 스코프 체인에 대한 것'이라고 생각했다. 때문에 모 회사의 면접에서 렉시컬 스코프를 설명하라는 질문에 부끄럽게도 스코프 체인에 대한 내용만 읊어버리고 말았다. 면접이 끝나고 이 두 개념이 다른 것이라는 말을 들었지만, 왜 다른 건지 뭐가 다른 건지 어떻게 다른 건지는 알 수 없었다. 이후 코어 자바스크립트와 YDKJSY를 읽으며 이 두 개념이 비슷하지만 확실히 다르다는 사실을 알게 되었다. 렉시컬 스코프는 변수와 함수가 어디에서 선언되었는지에 따라 그 유효 범위(scope)가 결정되는 원칙을 의미한다. 이는 정적으로 결정되며, 코드가 작성되는 위치에 따라 스코프가 결정된다. 즉, 함수가 어떤 코드 블록 내에서 선언..

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

중재자 패턴(Mediator Pattern)은 여러 객체들이 서로 직접 통신하지 않고, 중재자를 통해 상호작용하게 하여 시스템의 결합도를 낮추고 유연성을 제공한다. 예를 들어, 카페에서 손님은 바리스타에게 직접 주문하지 않고, 캐셔라는 중재자를 통해 주문을 전달하여 바리스타가 음료를 준비하게 된다. 음료 전달은 이 반대로 캐셔를 통해 손님에게 전달된다. 이를 통해 객체 간의 결합도를 낮추고 시스템을 더 유연하게 유지할 수 있다. 객체의 관계를 다대다에서 일대다로 변환한다는 점에서는 옵저버 패턴과 비슷하게 느껴질 수 있다. 하지만 옵저버 패턴이 주체 객체의 상태 변화를 여러 옵저버 객체들에게 자동으로 전달하는 데 반해, 중재자 패턴은 여러 객체들이 중재자를 통해 상호작용함으로써 객체들 간의 직접적인 의존성..

메멘토 패턴(Memento Pattern)은 객체의 내부 상태를 캡슐화하여 저장하고, 필요할 때 그 상태를 복원할 수 있게 한다. 상태 변화가 일어날 때마다 그 상태를 메멘토 객체로 저장하여 보관하고, 필요할 경우 복원할 수 있다. 주로 데이터의 손실 방지, 취소, 복구에 사용되기 때문에 적용 시나리오의 범위가 명확하고 제한적이다. 백업 전략을 선택하는 것은 시스템의 요구 사항에 따라 달라지며, 메멘토 패턴에서는 필요에 따라 상태를 저장하는 방식을 조정할 수 있다.다만, 객체 상태를 계속해서 저장하고 관리해야 하므로 메모리나 저장 공간의 사용에 신경을 써야 할 필요가 있다. 이 문제를 해결하기 위해 주로 전체 백업full backup과 증분 백업incremental backup이 사용된다. 전체 백업은 ..