프론트엔드

리액트 쿼리를 사용할 때 데이터를 깔끔하게 다루고 싶다는 욕구는 프론트엔드 개발자라면 누구나 한 번쯤 느꼈을 것이다. 특히 프로젝트 규모가 커지거나 API가 복잡해질수록, 네트워크 로직과 도메인 로직이 뒤섞이기 쉬운데, 이를 구조적으로 해결하고자 RAD 아키텍처를 적용해왔다. RAD는 API 요청의 추상화부터 응답 가공, 그리고 부가적인 기능(예: 로깅, 에러 핸들링, 토큰 처리 등)을 명확하게 분리할 수 있어 꽤 매력적인 구조였다.하지만 RAD의 마지막 축인 데코레이터는 리액트 쿼리와 잘 어울리지 않는 순간들이 있었다. React Query는 훅 기반으로 동작하기 때문에 훅의 규칙(예: 조건문 안에서 호출 불가, 컴포넌트 최상단에서만 호출 등)에 따라 데코레이터처럼 동작을 감싸는 방식이 오히려 제약으로..

이전에 [ 리액트 파이버를 통한 리랜더링 이해 ] 포스트를 통해 리액트가 어떻게 랜더링을 최적화하는지 살펴보았다. 이때 개인적으로는 아쉬움이 살짝 남았는데, 리액트가 랜더링을 효율적으로 처리하는 구조는 이해했지만, 언제 어떤 작업을 우선해서 처리하는지는 전혀 확인할 수 없었기 때문이다. 이번 포스트에서는 그 궁금증을 이어가며, React 18부터 도입된 Concurrent Rendering 환경에서 핵심적인 역할을 수행하는 RenderLane과 React Scheduler에 대해 알아보려 한다. 내부 구현에 가까운 개념이지만, 이를 이해하면 React의 렌더링 스케줄링이 어떤 기준으로 동작하는지, 그리고 실제 사용자 경험에 어떤 영향을 미치는지를 보다 명확하게 파악할 수 있다. RenderLaneRend..

React로 특정한 로직을 작성하다보면, 종종 내부 상태를 외부에서 제어하고 싶어질 때가 있다. 예를 들어 토글 버튼이 특정 조건을 만족할 때만 켜지게 하거나, 입력 값이 어떤 범위를 넘지 않도록 제한하고 싶은 경우가 그렇다. 단순히 상태를 끌어올리는 방식으로 해결할 수도 있지만, 이 방식은 재사용성을 떨어뜨리거나 로직이 분산되어 복잡해지는 단점이 있다.이럴 때 유용하게 사용할 수 있는 패턴이 바로 state reducer pattern이다. 이 패턴은 내부 상태 변경을 하나의 reducer 함수로 위임함으로써, 컴포넌트 내부 상태 로직에 외부 확장 포인트를 제공한다. 일반적인 useReducer의 개념과 유사하지만, 상태를 직접 관리하는 대신, 상태의 변경 과정을 중간에 가로채 수정하거나 거부할 수 있..

모달과 팝오버를 칼로 베듯 명확히 구분해본 적은 없었다. 그저 화면 한가운데에 떠서 다른 작업을 막으면 모달, 특정 버튼을 눌렀을 때 앵커를 기준으로 나타나면 팝오버라는 정도로 느슨하게 생각해왔다. 하지만 두 개념은 단순한 위치나 동작의 차이를 넘어, 그 목적과 사용 방식에서 뚜렷한 차이를 지닌다. 이를 제대로 이해하면 사용자 경험을 보다 세밀하게 설계할 수 있다.아래의 표에서 조금 더 체계적으로 정리해두었지만, 모달은 차단적 인터페이스다. 사용자가 모달을 닫기 전까지는 배경의 다른 요소와 상호작용할 수 없다. 이러한 차단성은 주로 중요한 작업을 처리하거나 사용자로부터 명확한 결정을 요구할 때 사용된다. 예를 들어, 삭제 확인 창이나 로그인 폼이 대표적이다.반면, 팝오버는 비차단적 인터페이스로, 배경과의..

웹 애플리케이션이 점점 복잡해짐에 따라, 메인 스레드에서 모든 작업을 처리하는 방식은 사용자 경험을 해칠 수 있다. 특히, 복잡한 계산 작업이나 I/O 작업이 길어질 경우 브라우저가 멈춘 것처럼 보이는 현상이 발생할 수 있다. 이를 해결하기 위한 방법 중 하나가 바로 Web Worker를 사용하는 것이다. Worker는 브라우저에서 제공하는 API로, 메인 스레드와는 별도의 스레드에서 JavaScript 코드를 실행할 수 있게 해준다. 이를 통해 계산이나 데이터 처리 등의 무거운 작업을 백그라운드에서 수행하게 하고, 메인 스레드의 반응성을 유지할 수 있다. Dedicated WorkerDedicated Worker는 Web Worker의 한 종류로, 하나의워커 인스턴스가 오직 하나의 메인 스레드와만 통..

LangChain은 AI 모델과 다양한 데이터 소스, 도구들을 연결해 복잡한 애플리케이션을 쉽게 구축할 수 있도록 돕는 프레임워크이다. 원래 파이썬 기반으로 많이 알려져 있지만, 최근에는 타입스크립트 지원도 활발해져 프론트엔드 개발자나 Node.js 환경에서도 효율적으로 활용할 수 있다. 타입스크립트 LangChain은 강력한 타입 시스템과 친숙한 문법 덕분에 안정적이고 생산성 높은 AI 통합 개발을 가능하게 한다. Basic Usage모델ChatOpenAI 인스턴스를 생성하는 것은 LangChain에서 OpenAI 기반 챗 모델을 사용하기 위한 첫 번째 단계이다. 이때 modelName, temperature, openAIApiKey 등의 옵션을 설정하여 사용할 모델의 종류, 응답의 창의성 정도, 인..

이번 주, sicilian과 caro-kann 모두 3.1 버전을 공개했다. 하나는 폼 관리 도구이고 다른 하나는 전역 상태 관리 도구라는 차이가 있지만, 이번 업데이트에서는 공통적으로 '런타임 타입 체크' 기능이 추가되었다. sicilian의 경우, 이전에도 내장된 validator를 통해 런타임 타입 검증이 가능했으나, zod, yup, superstruct와 같은 외부 스키마 라이브러리를 활용해 사용자 정의 검증 로직을 통합하는 방법은 존재하지 않았다. 그러나 3.1 버전부터는 이러한 스키마 라이브러리들과의 연동이 간편해졌고, 폼 데이터의 유효성 검사는 물론 구조와 타입까지도 런타임에서 명확하게 검증할 수 있게 되었다.sicilian에 외부 스키마 라이브러리를 통합하는 것은 오래전부터 품어온 염원이..

프론트엔드 개발자들 모인 자리에 가서 '어떤 스타일링 라이브러리 좋아하세요?'하고 물어보면 못해도 30분은 할 이야기가 생긴다. 내 경우에는 여러번 밝힌 바와 같이 TailwindCSS와 ModuleCSS를 선호한다. 하지만 내 선호를 밝히면 늘 돌아오는 질문이 있다. '그것들은 동적 스타일링하기 불편하지 않아요?'하고.요즘 사용자를 늘려가고 있는 Vanila-extract나 이제는 죽어버린 StyledComponent와 비교하면 앞서 언급한 두 라이브러리는 확실히 동적 스타일링에 취약하다. 특히 TailwindCSS는 빌드 과정에서 사용된 클래스 이름만 추출해서 최종 CSS를 생성하는 'content scanning' 과정이 필요한데, 이 때문에 아래와 같이 동적으로 클래스 이름을 조합하거나 조건부로 ..

프론트엔드 개발을 하다보면 백엔드가 없는 상태에서 일단 뷰를 완성해야 할 때가 있다. 프로젝트의 극 초기라면 백엔드 인터페이스가 하루에 두 번씩 변하는 만큼 난장판도 그런 난장판이 없다. 이런 환경에서 초기 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 ] 포스트를 통해 실제로는 커스텀 훅을 호출하기 위해 반드시 추가적인 커스텀 훅이 필요한 것은 아니며 ─ 각각의 규칙이 제시된 기저 이유를 깊게 이해한다는 전제 하에 ─ 클래스 내부에서도 훅을 사용할 수 있는 우회적인 방법이 존재한다는 사실을 알게되었다...