Ayden's journal

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

지금까지 진행한 대부분의 프로젝트에서는 Next.js의 페이지 라우터를 사용해왔지만, 이번에는 처음으로 앱 라우터(App Router)를 도입해보았다. 특별한 이유가 있었던 것은 아니고, 그저 기술적인 호기심 때문이었다. 서버 수준에서 처리되는 fetch cache나 서버 컴포넌트 개념처럼, 기존의 페이지 라우터에서는 경험할 수 없던 새로운 동작 방식을 직접 체험해보고 싶었다.기대가 없었다고 하면 거짓말이겠지만, 솔직히 말해 그 일말의 기대조차 보기 좋게 배신당했다. 새로운 구조는 분명 매력적으로 보였지만, 실제로 마주한 현실은 생각보다 복잡하고 어수선했다. 디렉토리 구조는 지나치게 제약이 많았고, 서버 컴포넌트와 클라이언트 컴포넌트의 경계를 의식하며 코드를 짜는 일은 흐름을 자주 끊어놓았다. 페이지 라..

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

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

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

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

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

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

전역 상태 관리 도구

form 상태 관리 도구