분류 전체보기

프론트엔드 개발을 하다보면 백엔드가 없는 상태에서 일단 뷰를 완성해야 할 때가 있다. 프로젝트의 극 초기라면 백엔드 인터페이스가 하루에 두 번씩 변하는 만큼 난장판도 그런 난장판이 없다. 이런 환경에서 초기 Mock 데이터를 통해 뷰를 구성하고, 이후 백엔드 인터페이스를 연결하는 일련의 과정을 나는 Mock First Development라고 부르고 있다.이번 포스트에서는 아주아주 간단한 '프로필 기능'을 만들어보며 [ RAD 아키텍처 ] 를 활용해 안전하게 Mock First Development를 수행하는 일련의 과정을 간단히 알아보고자 한다. Adaptor와 MockRAD 아키텍처의 A to Z는 어댑터 클래스에 있다고 해도 과언이 아니다. 우선 백엔드 인터페이스가 어떤 모습이 될 지는 모르겠지만,..

RAD 아키텍처는 데코레이터를 적극적으로 사용해 여러 클래스 훅에서 동일하게 처리되어야 할 관심사를 횡적으로 분리한다. 나는 주로 세 가지 데코레이터를 사용하는데, thisBind∙transformResult∙transformArgs가 그것이다. 이 포스트에서는 각각의 데코레이터가 어떤 관심사를 처리하는지 알아보고자 한다. thisBind 클래스 데코레이터[ the Rules of Hooks in a class-based architecture ] 에서 나는 this binding의 문제로 인해 함수 선언문보다는 함수 표현식을 권장한다고 말했다. 그러나 이후에 살펴볼 transformResult나 transformArgs 데코레이터를 '하나의 메서드'에 동시에 적용하기 위해서는 함수 선언문을 사용해야 한..

원래는 "프론트엔드에서 데이터를 페칭할 때 리액트 쿼리를 효과적으로 구조화하기 위해 레포지토리 패턴, 어댑터 패턴, 데코레이터를 활용하는 아키텍처"인데, 내가 워낙 이름 짓는데 소질도 없고 하여 적용되는 패턴들의 앞글자를 따 RAD 아키텍처라 부르고 있다.레포지토리 패턴은 데이터 액세스를 추상화하여, 컴포넌트가 서버와 직접적으로 상호작용하지 않도록 한다. 어댑터 패턴은 서버에서 반환되는 데이터 구조를 클라이언트에서 필요로 하는 형태로 변환하고, 데코레이터는 각 메서드에 직접적으로 어댑터를 적용한다. 이를 도표로 나타내면 아래와 같다. RAD 아키텍처는 Query 흐름과 Mutation 흐름을 분리하여 설계한다. 다만 근본적인 구조 자체는 동일하다 할 수 있기에 이 포스트에서는 ─ 분량이 너무 늘어날까봐 ..

[ data fetching on react.js ] 에서 나는 Fetcher ➠ Query ➠ DomainQuery로 이어지는 클래스의 상속 관계 끝에 뜬금없이 useAdaptor라는 훅을 끼워넣었다. 이는 일반적인 훅의 규칙을 따르기 위함이었다. useQuery나 useMutation와 같은 커스텀 훅을 호출하기 위해서는 반드시 추가적인 커스텀 훅이 필요하다는 것이 이 바닥의 상식이다.그러나 나는 [ Breaking the Rules of Hooks ] 포스트를 통해 실제로는 커스텀 훅을 호출하기 위해 반드시 추가적인 커스텀 훅이 필요한 것은 아니며 ─ 각각의 규칙이 제시된 기저 이유를 깊게 이해한다는 전제 하에 ─ 클래스 내부에서도 훅을 사용할 수 있는 우회적인 방법이 존재한다는 사실을 알게되었다...

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

우선 밝혀두자면 이 포스트는 단 하나의 궁금증으로부터 출발했다. '어떻게 input 태그는 state 없이 ─ 그리하여 리랜더링 없이 ─ value 값을 변경하지?' 보통은 input:value에 state를 달아 제어 컴포넌트로 만들지만, 그렇게 하지 않아도 input은 멀쩡히 동작한다. 당장 리액트 커뮤니티에서 가장 광범위하게 사용되는 form 관리 라이브러리 중 하나인 react-hook-form만 하더라도 ref를 기반으로 동작하니까. state 없이도 DOM이 변경되는지를 확인해보기 위해 아래와 같은 테스트 코드를 작성해보았다. 버튼을 누르면 input:value의 값을 div의 innerText로 박아버리는 아주 간단한 동작을 처리한다.export default function Page() {..

현대의 개발 환경에서 도커(Docker)는 빠르게 개발하고 배포할 수 있는 핵심 도구로 자리 잡았다. 도커를 사용하면 애플리케이션 실행 환경을 컨테이너라는 독립된 단위로 포장할 수 있으며, 이를 통해 운영체제에 관계없이 동일한 환경에서 애플리케이션을 실행할 수 있다. 이러한 장점 덕분에 개발, 테스트, 배포 전반에 걸쳐 일관성을 유지할 수 있으며, 특히 팀 협업 시 환경 차이로 인한 문제를 크게 줄일 수 있다. 이미지 관리도커에서 이미지(Image)란 컨테이너 실행에 필요한 파일 시스템과 설정 정보를 포함한 읽기 전용 템플릿이다. 애플리케이션 코드, 라이브러리, 의존성, 환경 변수, 실행 명령어 등이 포함되어 있으며, 컨테이너는 이 이미지를 기반으로 실행된다. 쉽게 말해, 이미지는 컨테이너의 '설계도'..

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

CSS를 다루다 보면 뷰포트 크기에 따라 유동적으로 변화하는 레이아웃이나 폰트 크기를 구현해야 하는 경우가 많다. 이때 반응형 디자인을 유연하게 만들어주는 함수들이 바로 min(), max(), clamp()이다. 이 함수들은 각각 최소값, 최대값, 그리고 범위를 지정한 선호값을 설정할 수 있도록 도와주며, CSS 속성에서 숫자 단위를 계산할 수 있는 기능을 제공한다.기존에는 미디어 쿼리로 복잡하게 처리하던 작업들도 이 함수들을 사용하면 훨씬 간결하고 직관적으로 구현할 수 있다. 특히 clamp() 함수는 하나의 속성 값에 최소값, 선호값, 최대값을 한 번에 설정할 수 있어 반응형 타이포그래피나 요소 크기 조절에 매우 유용하다. min() 함수는 여러 개의 값 중 가장 작은 값을 선택한다. 주로 widt..