dev.jung

React useEffect 의존성 배열과 stale closure 이해하기

React를 배우다 보면 useEffect의 두 번째 인자인 의존성 배열을 자주 만납니다. 특히 []를 넣으면 “처음 한 번만 실행된다”고 외우기 쉽지만, 실무에서는 이 이해만으로 부족합니다.useEffect는 렌더링 이후 React 바깥의 시스템과 컴포넌트를 동기화할 때 쓰는 Hook입니다. 여기서 외부 시스템은 타이머, 이벤트 리스너, 네트워크 구독, 브라우저 API처럼 React 밖에서 살아 있는 대상을 뜻합니다.의존성 배열은 실행 횟수 옵션이 아니다의존성 배열은 effect가 어떤 값에 반응해야 하는지를 React에 알려주는 목록입니다. props, state, 컴포넌트 안에서 만든 변수나 함수처럼 렌더마다 바뀔 수 있는 값이 effect 안에서 쓰인다면, 그 값은 의존성 후보입니다.따라서 []는..

React Hydration과 Selective Hydration 쉽게 이해하기

Next.js처럼 서버 렌더링을 사용하는 React 앱을 다루다 보면 hydration mismatch 경고를 한 번쯤 만나게 됩니다. 단순한 경고처럼 보이지만, 실제로는 서버가 만든 HTML과 브라우저에서 React가 처음 계산한 화면이 서로 맞지 않는다는 신호입니다.이번 글에서는 hydration이 무엇인지, 왜 서버와 클라이언트의 첫 렌더 결과가 같아야 하는지, 그리고 React 18 이후의 selective hydration이 어떤 문제를 줄이려는지 정리해보겠습니다.Hydration이란?Hydration은 서버가 먼저 만들어 둔 HTML에 React의 이벤트와 상태를 연결하는 과정입니다.서버 렌더링으로 내려온 HTML은 처음에는 정적인 마크업에 가깝습니다. 화면은 보이지만, 아직 버튼 클릭이나 입..

Next.js loading.tsx와 Suspense 차이 이해하기

Next.js App Router를 쓰다 보면 loading.tsx와 를 함께 만나게 됩니다. 둘 다 “로딩 중에 무엇을 보여줄 것인가”를 다루기 때문에 처음에는 같은 역할처럼 보입니다.하지만 실제로는 적용되는 위치가 다릅니다. loading.tsx는 Next.js 라우트 세그먼트 단위의 로딩 UI이고, 는 React 컴포넌트 트리 안에서 특정 영역을 기다리게 만드는 경계입니다.핵심은 간단합니다. “페이지 전체를 기다릴 것인가, 페이지 안의 일부만 기다릴 것인가”를 구분하는 것입니다.loading.tsx는 라우트 단위의 기본 로딩 화면loading.tsx는 Next.js App Router의 파일 규칙입니다. 특정 라우트 세그먼트에 loading.tsx를 두면, 해당 세그먼트의 페이지가 준비되는 동안 N..

Next.js revalidateTag와 updateTag 차이 정리

Next.js App Router를 쓰다 보면 서버에서 가져온 데이터를 캐시하고, 필요한 순간에만 다시 갱신해야 하는 상황이 자주 생깁니다. 게시글 목록, 상품 재고, 공지사항처럼 “항상 새로 가져오면 비싸지만, 바뀌었을 때는 빨리 반영되어야 하는 데이터”가 대표적입니다.이때 자주 등장하는 개념이 revalidate, revalidateTag, updateTag입니다. 이름은 비슷하지만 역할은 다릅니다. 핵심은 시간 기준으로 오래된 데이터를 갱신할 것인지, 태그 기준으로 특정 데이터만 무효화할 것인지, 사용자 액션 직후 바로 새 값을 보장할 것인지입니다.revalidate는 시간 기반 캐시 정책이다revalidate: 60은 캐시된 데이터를 60초 동안 재사용하겠다는 뜻입니다. 이 시간 안에는 같은 데이..

Next.js Server Component와 Client Component 기준

요약: Next.js App Router에서 Server Component와 Client Component를 나누는 기준을 실행 위치, 상호작용, props 직렬화 관점에서 정리합니다. use client를 언제 붙여야 하는지 간단한 카운터 예제로 확인합니다.Next.js App Router를 쓰다 보면 가장 자주 만나는 질문이 있습니다. “이 컴포넌트에 use client를 붙여야 하나?”입니다. 결론부터 말하면 기준은 파일 위치가 아니라 어느 런타임에서 실행되어야 하는가입니다.Server Component는 서버에서 데이터와 HTML을 준비하는 역할에 가깝고, Client Component는 브라우저에서 상태와 상호작용을 담당합니다. 이 경계를 이해하면 use client 에러, 이벤트 핸들러 전달 ..

React 렌더링 비용과 브라우저 렌더링 비용의 차이

프론트엔드 성능 최적화를 하다 보면 “렌더링 비용을 줄인다”는 말을 자주 듣습니다. 그런데 여기서 말하는 렌더링이 항상 같은 의미는 아닙니다.React에서 말하는 렌더링 비용과 브라우저가 실제 화면을 그리는 렌더링 비용은 서로 다른 계층의 문제입니다. 이 둘을 구분하지 못하면 최적화 방향이 쉽게 빗나갑니다.예를 들어 React Profiler에서 특정 컴포넌트가 불필요하게 자주 렌더링되는 상황인데 CSS 속성만 조정하거나, 반대로 레이아웃 계산이 병목인데 React.memo만 붙이는 식의 실수가 생길 수 있습니다.React 렌더링 비용이란?React 렌더링 비용은 컴포넌트 트리 안에서 발생하는 비용입니다.상태나 props가 바뀌면 React는 어떤 컴포넌트를 다시 계산해야 하는지 판단하고, 컴포넌트 함수..

React Context와 useSyncExternalStore 차이 이해하기

React에서 전역 상태를 다루다 보면 Context와 useSyncExternalStore를 함께 마주치게 됩니다. 둘 다 여러 컴포넌트에서 값을 읽는 데 쓰일 수 있어서 비슷해 보이지만, 실제 역할은 꽤 다릅니다.한 줄로 정리하면 이렇습니다. Context는 React 트리 안에서 값을 전달하는 도구이고, useSyncExternalStore는 React 바깥에서 변하는 값을 React 렌더링 흐름에 맞게 구독하는 도구입니다.Context는 값을 전달하는 도구다React Context는 props를 여러 단계로 계속 넘기지 않아도 하위 컴포넌트에서 공통 값을 읽을 수 있게 해줍니다. 테마, 로그인 사용자, 언어 설정, 앱 전역 설정처럼 여러 컴포넌트가 함께 알아야 하는 값을 내려줄 때 유용합니다.하지..

React Context와 memo, 왜 다시 렌더링될까?

React에서 렌더링 최적화를 하다 보면 React.memo와 Context를 함께 사용하는 경우가 많습니다. 그런데 분명 memo로 컴포넌트를 감쌌는데도 다시 렌더링되는 상황을 만날 때가 있습니다.핵심은 간단합니다. React.memo는 props 비교를 통해 렌더링을 건너뛰는 도구이고, useContext는 Provider의 value 변경을 구독합니다. 즉 props가 그대로여도 컴포넌트 내부에서 Context를 읽고 있다면 Context 값 변경에 따라 다시 렌더링될 수 있습니다.React.memo가 해주는 일React.memo는 부모 컴포넌트가 다시 렌더링될 때 자식 컴포넌트의 props가 이전과 같은지 비교합니다. props가 같다면 React는 해당 컴포넌트의 렌더링을 건너뛸 수 있습니다.c..

React.memo가 안 먹히는 이유: props 참조 안정성 이해하기

React에서 성능 최적화를 하다 보면 React.memo를 자주 만나게 됩니다. 이름만 보면 컴포넌트 렌더링을 자동으로 줄여주는 도구처럼 느껴지지만, 실제로는 조건이 맞을 때만 효과가 있습니다.특히 React.memo를 적용했는데도 자식 컴포넌트가 계속 렌더링된다면, 가장 먼저 봐야 할 것은 props의 참조 안정성입니다.React.memo는 무엇을 비교할까?React.memo는 컴포넌트의 이전 props와 다음 props를 비교합니다. 두 props가 같다고 판단되면 해당 컴포넌트의 렌더링을 건너뜁니다.여기서 중요한 점은 기본 비교 방식이 얕은 비교라는 것입니다.숫자, 문자열, boolean 같은 원시값은 비교가 쉽습니다. 값 자체가 같으면 같은 props로 볼 수 있습니다. 하지만 함수, 객체, 배..

React key는 왜 중요할까? index key가 위험한 이유

React로 리스트를 렌더링하다 보면 한 번쯤 이런 경고를 만난다.각 리스트 항목에는 고유한 key가 필요합니다.처음에는 단순히 경고를 없애기 위해 key를 넣는 경우가 많다. 하지만 React의 key는 경고 제거용 속성이 아니다. 리스트 안에서 “이 항목이 어떤 데이터인지”를 React에게 알려주는 식별자다.특히 입력창, 체크박스, 포커스, 애니메이션, 내부 state가 있는 리스트에서는 key 선택이 실제 버그로 이어질 수 있다.React key는 항목의 정체성을 알려준다React는 상태가 바뀔 때마다 JSX 결과를 다시 만들고, 이전 렌더 결과와 다음 렌더 결과를 비교한다. 이 과정을 통해 어떤 부분을 유지하고 어떤 부분을 바꿀지 판단한다.문제는 리스트다. 리스트에는 같은 컴포넌트가 여러 번 반복..