process.env 값을 구조 분해 할당 하셨나요? 우리가 환경변수를 접근할 때 객체의 속성값에 접근할 때 사용하는 점 표기법을 사용하기 때문에 구조 분해 할당을 자연스럽게 사용해도 될 것 같은데요. 이런 경우, 왜 에러가 발생하는지 이번 글을 통해 알아보겠습니다. 문제 상황 다음과 같은 코드가 있다고 가정해 봅시다. 위 코드는 process.env 객체에서 API_KEY와 NEXT_PUBLIC_ANALYTICS_ID 변수를 구조 분해 할당하여 사용하려고 합니다. 그러나 Next.js에서는 이 코드가 제대로 작동하지 않을 수 있고, 오류가 발생할 수 있습니다. 왜 이런 문제가 발생할까요? process.env는 일반적인 자바스크립트 객체와는 다르기 때문입니다. 이는 Node.js 환경에서 환경 변수를 담고 있는 특수한 객체로, 모든 속성이 문자열 형태로 저장됩니다. Next.js는 빌드 타임과 런타임에서 환경 변수에 접근하는 방식이 다르므로, 이로 인해 구조 분해 할당을 사용할 …

원글: https://aralroca.com/blog/html-node-streaming 썸네일 최근 몇 년간 브라우저는 HTML과 자바스크립트를 스트리밍을 지원하기 시작했습니다. 이 글에서는 이에 대한 장점과 브라우저가 자동으로 수행하지 않는 다른 작업들을 통해 스트리밍의 이점을 최대한 활용할 수 있는 방법에 대해 이야기할 것입니다. 스트리밍 HTML 초기 로드하는 동안에는 브라우저가 자동으로 처리하기 때문에 크게 신경 쓸 필요가 없습니다. 스트리밍 하는 동안 HTML 청크를 받으면, 브라우저는 그 콘텐츠를 출력합니다. 서버에서 스트리밍을 활성화하려면 헤더를 조정해야 합니다. 아래는 예시입니다. 그리고 응답에서는 ReadableStream을 사용합니다. 이것은 Bun을 사용한 예시입니다. enqueue 안에 있는 각 문자열은 브라우저가 받게 될 청크입니다. 스트리밍 중 HTML 콘텐츠 변경 성능상의 이점이 많기 때문에 많이 사용되는 방법 중 하나는 스트리밍 되는 동안 HTML 콘…

원문: https://storybook.js.org/blog/storybook-react-server-components/ 스토리북 8.0 알파 업그레이드를 통한 스토리북에서 RSC 사용 리액트 서버 컴포넌트 (RSC)는 리액트 기반 웹 UI의 새로운 프로그래밍 모델입니다. 기존의 전통적인 리액트 “클라이언트” 컴포넌트와 달리, 서버에서만 렌더링됩니다. 이는 다양한 성능 및 보안 이점을 가져오지만, 기존의 리액트 도구 및 라이브러리와는 크게 다릅니다. 가장 크게 영향을 받는 부분 중 하나는 컴포넌트 기반 개발 및 테스트입니다. 스토리북, 테스팅 라이브러리 및 Playwright/Cypress와 같은 컴포넌트 테스팅과 같은 도구들은 사용자의 컴포넌트가 브라우저 (또는 JSDom)에서 렌더링되고 있다고 가정합니다. 그러나 서버 컴포넌트의 경우, 이러한 가정이 성립하지 않습니다. 이로 인해, 서버를 위한 격리된 컴포넌트 개발 및 테스트를 수행하는 것이 무엇을 의미하는가? 라는 의문이 …

지난 글에서 react-query의 hydrate, dehydrate을 통해 서버에서 prefetching 한 데이터 사용하는 방법에 대해서 살펴보았습니다. 서버에서 prefetching 한 데이터 사용하기 오늘은 조금 실용적으로 Next.js 13, 14 버전의 app router에서 react-query를 어떻게 사용하고 세팅하면 좋을지 고민했던 내용에 대해서 이야기해보도록 하겠습니다. 해당 글은 23년 10월에 메이저 버전 업데이트된, Next.js 14와 React-Query 5 를 기준으로 작성된 글입니다. 예시로 보여주는 코드는 저의 next-14-react-query repo에서 확인 할 수 있습니다. 제가 크게 고민했던 문제는 아래 세 가지입니다. Hydrate vs ReactQueryStreamedHydration 두 가지 API 중에 어떤 것을 채택할까? Hydration API 사용 시에 RSC, RCC 모두에서 깔끔한 코드를 유지하려면 queryOption은 …

Next.js나 Remix 같은 프레임워크 내에서 React-Query를 사용한다면, 서버 렌더링 될 때 요청 후 응답받은 데이터를 SPA 방식으로 전환되고 나서도 유지할 수 있을까요? 어떻게 가능할까요? React Query의 hydrate와 dehydrate는 서버에서 미리 가져온 데이터를 클라이언트 사이드에서 재사용 할 수 있게 해줍니다. 이번 글을 통해 서버 렌더링과 어떻게 이를 가능하게 하는지 hydrate와 dehydrate에 대해서 알아봅시다. Server Rendering 서버 렌더링은 사용자가 페이지를 로드하는 즉시 볼 수 있는 초기 HTML을 서버에서 생성하는 행위입니다. 이는 페이지 요청 시 즉시 발생할 수 있으며(SSR), 이전 요청이 캐시 되었거나 빌드 시간에 미리 생성(SSG) 할 수도 있습니다. 클라이언트 렌더링 애플리케이션에서는 사용자에게 화면에 콘텐츠를 표시하기 전에 최소 3번의 서버 왕복(roundtrips)이 필요합니다. 서버 렌더링은 위의 과정…

원문: https://preactjs.com/blog/introducing-signals/ 시그널은 앱이 복잡해져도 빠른 속도를 유지하도록 하는 상태 표현 방식입니다. 시그널은 반응형 원칙에 기반을 두고 있으며, 가상 돔에 최적화된 독특한 구현을 통해 개발자에게 훌륭한 경험을 제공합니다. 본질적으로 시그널은 특정 값을 가지고 있는 .value 속성을 가진 객체입니다. 컴포넌트 내에서 시그널의 value 속성에 접근하면, 그 시그널의 값이 변경될 때 해당 컴포넌트가 자동으로 업데이트됩니다. 이는 간단하고 작성하기 쉬울 뿐만 아니라, 앱이 얼마나 많은 컴포넌트를 가지고 있든 상태 업데이트가 빠르게 유지되도록 보장합니다. 시그널은 기본적으로 빠르며, 백그라운드에서 자동으로 업데이트를 최적화해줍니다. REPL에서 실행 시그널은 훅과 달리 컴포넌트 내부 또는 외부에서 사용할 수 있습니다. 또한 시그널은 훅과 클래스 컴포넌트 모두에서 훌륭하게 작동하므로, 기존 지식을 활용하며 자신의 속도에 …

원글: https://itnext.io/decoupling-ui-and-logic-in-react-a-clean-code-approach-with-headless-components-82e46b5820c 프런트엔드 개발 영역에서는 용어와 패러다임이 때로는 이해하기 어려울 수 있으며 ‘헤드리스 UI’ 또는 ‘헤드리스 컴포넌트’도 이 범주에 속할 수 있습니다. 이러한 용어들이 무엇을 의미하는지 궁금해서 고개를 갸웃거리고, 혼자만 그런 것이 아닙니다. 사실, 혼란스러운 이름에도 불구하고 이러한 개념들은 복잡한 사용자 인터페이스 관리를 상당히 단순화할 수 있는 매력적인 전략입니다. 헤드리스 컴포넌트는 난해해 보일 수 있지만, 그 진정한 힘은 유연성, 재사용 가능성, 그리고 코드베이스의 구성과 깔끔함을 향상시킬 수 있는 능력에 있습니다. 이 글에서는 이 패턴이 정확히 무엇인지, 왜 유용한지, 그리고 인터페이스 디자인에 대한 접근 방식을 어떻게 혁신할 수 있는지에 대해 탐구해 볼 것입니다. …

원문: https://www.tecforfun.com/frameworks/how-to-manage-server-state-with-react-query/ React Query는 React 애플리케이션에서 데이터 페칭과 캐싱 프로세스를 간소화하는 라이브러리입니다. 이 라이브러리는 API와 기타 데이터 소스로부터 데이터를 페칭하고 업데이트하는 데 필요한 도구와 유틸리티를 제공하며 데이터 페칭의 상태와 캐싱을 자동으로 관리합니다. 이 라이브러리는 React 컴포넌트에서 데이터를 더 쉽게 다룰 수 있도록 다양한 훅과 유틸리티를 제공합니다. 이 포스트에서는 React Query의 주요 기능에 대해 이야기하겠습니다. 여기서 제 목적은 가능한 한 빨리 React Query를 사용하여 작업을 시작할 수 있는 출발점을 제공하는 것입니다. React 앱 개발에 경험이 있다면, 클라이언트 상태 관리를 위해 Redux와 같은 라이브러리를 사용한 적이 있을 수 있습니다. 반면에, React Query는 …

React 18로 버전업 하면서 프로젝트에 Recoil을 도입했는데, 그 과정에서 고민했던 내용을 기록차 남겨본다. TL;DR; 개념 정리나 장단점 비교에 대해서는 이미 알고 계신분들도 있을 것 같아서 폴더구조나 Redux를 대체하는게 맞는가에 대해서만 먼저 간단하게 요약한 내용을 공유한다. 1. 폴더 구조는 data source 별로 나누자 Suggested folder structure for atoms and selectors recoil 폴더 하위에 data source 별로 나누자 data source 하위에 atoms, selectors, hooks를 두자 2. concurrency mode 사용하려면 Redux는 버리고 Recoil로 넘어가야하나? useSyncExternalStore hook 을 사용해서 Redux에서도 동시성 모드를 사용할 수 있다. 이 부분에 대해서 고민해 본 내용은 아래에.. Recoil 도입 배경 Recoil은 Facebook에서 개발한 상태…

Introduction #1077 이슈를 보면 mutateFn의 variable을 필수값으로 변경한 이력을 볼 수 있다. mutation인데 왜 variable이 없냐고? 나의 경우에는 URL의 있는 queryParams를 읽어와서 데이터를 넘겨주면 되기 때문에 useSomething hook 안에서 처리하고 싶었다. 문제상황 mutate() 와 같이 variable에 아무 값도 넣지 않고 mutation 함수를 호출 할 수 없다. TVariables 타입에 undefined도 줘보고 이래저래 별짓을 다해봐도 필수값을 optional 하게 바꿀수는 없었다. 에러 발생 해결 실질적으로는 mute 함수에서 variable을 정의해서 넣어주는 것이기 때문에 그렇게 꼼수해결법도 아니다.

Introduction 이 글을 읽기전 React의 상태관리 종류 4가지를 먼저 읽으면 이해가 쉬울 수 있다. 얼마전 회사 프로젝트에 react-query를 도입하여 사용중인데 정말 너무너무 좋다. react-query를 이용해서 server state를 분리하다보니 loading 처리나, refetch 등 불필요한 코드가 많이 줄었다. 뭐든지 처음이 어렵지 큰 그림을 알고있으면 도입하여 적용하는데에는 큰 문제가 없고, 사용하면서 상황에 맞게 옵션과 아키텍쳐를 변경하면 된다고 생각하기 때문에, 이번 포스팅에서는 react-query를 적용하기 위해 필요한 전반적인 개념을 정리해보고자 한다. 용도 react-query는 서버 데이터 관리를 위한 라이브러리다. 이 라이브러리는 API 호출, 캐시 및 상태 관리, 오류 처리 등의 작업을 간단하게 처리할 수 있도록 도와준다. 서버 데이터 관리는 중요한 부분 중 하나다. 클라이언트에서는 서버로부터 데이터를 가져와(Read) 화면에 그려주고…

Introduction react의 상태관리 종류 4가지를 알아보고, 각각의 종류별로 왜 다르게 관리해야하는지와 React에서 제공하는 API 혹은 어떤 라이브러리를 사용해서 관리하면 좋을지 알아보도록 하자. 상태관리 종류 Local state Global state App 어느곳(여러 컴포넌트)에서 state를 확인하거나 업데이트하기 위해서 필요함. 예: authenticated user state - logged in/out Server state 서버로 받은 데이터가 UI 상태와 통합되어야 하는 경우 필요함. 예: loading, error… 대표 라이브러리: SWR, react-query URL state URL에 존재하는 데이터(pathname, query params..) 1) Local state useState useReducer useReducer vs useState 차이 useState는 하나의 state operation만 가능했다면, useReducer는 여…

고민 혹시 제가 내린 결론에 다른 의견을 주신다면 매우 감사합니다. 🙇🏻‍♀️ 에러를 발생 vs 사전 확인을 통해 예외 처리 어느 부분까지 사전 확인이 필요한 걸까? 고민하게 된 배경 함수의 매개변수가 의도한 것과 다른 값이 들어왔을 때 에러가 발생할 수 있다. 그런데 문득 에러를 발생하게 하는 게 올바른 것인가? 아니면 애초에 에러가 발생할 상황을 하나도 빠짐없이 막는 것이 올바른 것인가? 고민이 들었다. 위의 코드를 보면 event 객체가 무조건 존재할 상황을 가졍하고 있으므로 만약 비정상적인 event 객체가 첫 번째 인자로 전달된다면 에러가 발생할 것이다. 그렇다면 이렇게 코드를 짜는 것이 좋을까? 애초에 event 객체가 존재하지 않을 수 있는 케이스를 고려해서 절대로 에러를 발생하지 않게 하는 것이 좋을까? 결론 App을 Crashed 시키지 않는 한해서 에러가 발생해야 하는 경우는 발생하게 내버려 두고, 예상할 수 있는 예외는 try…catch를 이용하여 에러가 전파되지 않도…