분류 전체보기

최근 프로젝트에서 유저 인증 로직을 백엔드가 쿠키에 JWT 토큰을 심는 방식으로 처리하기로 결정했다. 클라이언트에서는 fetch나 React Query 호출 시 credentials: "include"만 설정하면 브라우저가 자동으로 쿠키를 보내주기 때문에, 사실상 별다른 작업 없이 인증이 적용된다.하지만 Next.js를 쓰면서 서버 사이드에서 이루어지는 로직, 예를 들어 getServerSideProps나 API 라우트에서 데이터를 불러오는 과정에서는 이야기가 달라진다. 페이지 라우팅마다 fetcher 호출이 발생하고, 요청 단위로 쿠키를 전달해야 하는 상황이 반복적으로 등장한다. 매번 쿠키를 직접 fetch 옵션에 넣어주거나, 요청 객체를 계속 전달해야 하는 번거로움이 존재한다.이런 반복적인 귀찮음을 ..

내가 만든 전역 상태 관리 도구인 caro-kann, 모달 처리 도구 grunfeld, 폼 관리 도구 sicilian은 이제 모두 @ilokesto라는 단일 네임스페이스 아래에서, 예를 들어 @ilokesto/caro-kann과 같은 형태로 제공된다. 이런 구조는 패키지 관리와 버전 통일성을 위해 매우 유용하며, 사용자 입장에서도 어떤 라이브러리가 같은 생태계에 속해 있는지 직관적으로 이해할 수 있다.반면 neato는 내가 직접 만들고 배포하고 있음에도, @ilokesto 네임스페이스에 속하지 않는 조금은 특이한 케이스다. 다른 라이브러리들과 달리 핵심 기능 대부분은 clsx나 tailwind-merge 같은 검증된 외부 라이브러리에 의존하고 있으며, 나는 Tailwind 환경에서 필요한 보조 기능들, ..

웹 애플리케이션의 사용자 경험은 상태 전환의 자연스러움에 크게 좌우된다. 사용자가 리스트에서 항목을 선택해 상세로 들어가거나, 카드가 화면에서 커다란 히어로 이미지로 확장되는 장면이 부드럽게 이어지면 인터페이스는 훨씬 더 신뢰감을 준다. 과거에는 이런 효과를 만들려면 복잡한 DOM 측정·계산·동기화 로직을 직접 구현해야 했지만, View Transitions API는 브라우저 수준에서 '상태 변경을 알려주면 알아서 전환을 처리'하는 패러다임을 제시한다.전통적인 전환은 개발자가 이전 상태와 이후 상태를 둘 다 직접 다루고, 애니메이션 타이밍을 맞추며, 엔터/엑시트 애니메이션을 수동으로 제어해야 했다. View Transitions API는 이 과정을 단순화한다. 개발자는 "이제 상태를 바꾼다"는 사실만 브..

본 포스트의 모든 코드와 예제는 GitHub의 @ilokesto/sicilian 레포지토리에서 확인 가능합니다. 좋은 라이브러리를 만들었다 한들 쓰는 게 귀찮으면 아무짝에도 쓸모가 없다. 가령 sicilian이 그렇다. 다른 라이브러리들도 아마 비슷한 면이 있겠지만, sicilian의 경우 특히 form을 구성하는 요소들에 대한 옵트인 옵션이나, 리턴되는 객체에 포함된 메서드와 값을 일일이 선언해야 하는 번거로움이 있었다.문제는 이런 반복적인 선언 과정이 단순히 개발자의 귀찮음을 넘어, 실제로는 생산성을 저해하고 진입 장벽을 높이는 요인이라는 점이다. 즉, 라이브러리의 기능이 아무리 훌륭해도 "시작하기 힘들다"라는 인상이 남는 순간, 대부분의 사용자는 대안을 찾아 떠나게 된다. 나 스스로도 매번 boil..

이 포스트는 [Domain-Oriented Data Fetching in React Query]에서 소개한 구조를 바탕으로, Next.js App Router 환경에서 React Query와 기본 fetch API를 조화롭게 사용하는 방법에 대한 확장 설명이다. 특히 서버 컴포넌트 중심의 렌더링 패턴과 React Query의 캐싱·하이드레이션 기능을 어떻게 통합적으로 활용할 수 있는지를 구체적으로 다룬다.본 글은 일종의 부록 역할을 하며, 기본적인 도메인 중심 데이터 패칭 구조나 Fetcher, Query 클래스 구조 등에 대한 설명은 앞서 소개한 포스트를 참고하는 것을 권장한다. 이 글에서는 해당 구조를 Next.js의 서버 사이드 렌더링 및 클라이언트 하이드레이션 흐름에 어떻게 녹여낼 수 있는지를 중..

객체지향이라는 개념을 접하게 된 것은 개발을 시작하고 얼마 지나지 않았을 때였다. 데이터와 그 데이터를 다루는 메서드가 하나의 객체 안에서 긴밀하게 연결되어 동작한다는 것과, 이러한 객체들이 유기적으로 협력하며 하나의 시스템을 구성한다는 개념이 내게는 어떠한 계시처럼 느껴졌다. 그 이후로 나는 이 개념의 아름다움에 깊이 매료되어, 프론트엔드 개발 전반에서 이를 어떻게든 구현해보려 애썼다.지금은 존재하지 않지만 한때 이 블로그에 작성한 포스트들 ─ 어댑터 패턴을 활용한 프론트엔드 주도 개발, RAD 아키텍처 등 ─ 은 모두 백엔드에서 데이터를 가져오는 방식에 객체지향적 사고를 어떻게 녹여낼 수 있을지 고민한 흔적들이었다. 그러나 지금까지의 고민들은 클래스와 인스턴스를 사용하기는 했어도 본질적으로 객체지향적..

상황나는 page router를 좋아하지만, 이번에는 여러 사정이 있어서 app router를 쓰게 되었다. 이왕 쓰게 된 김에 이런 저런 기능을 몽땅 활용할 생각이었다. 가장 기대하던 기능은 데이터 캐싱이었는데, 가능한 많은 걸 캐싱해두면 랜더링 완료 시점을 한참 일찍 앞당길 수 있을 거란 기대가 있었다.나는 여러 캐싱 기능을 테스트해보기 위해 아래와 같은 코드를 작성했다. 백엔드에서 랜덤한 기술 질문을 하나 가져오고, ─ 원래라면 revalidate: 10 을 넣었겠지만 ─ 캐시에 TTL 없이 보관하는 설정을 시험해보고자 cache: "force-cache"로 지정해 fetch 요청을 캐싱했다. 이렇게 하면 빌드 시점 이후에는 동일한 요청에 대해 항상 캐시된 데이터를 반환하게 되며, 의도한 대로라면 ..

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

웹 애플리케이션이 점점 복잡해짐에 따라, 메인 스레드에서 모든 작업을 처리하는 방식은 사용자 경험을 해칠 수 있다. 특히, 복잡한 계산 작업이나 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에 외부 스키마 라이브러리를 통합하는 것은 오래전부터 품어온 염원이..

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