코드 땜장이

React 리렌더링을 줄이는 실전 기준: memo, useMemo, useCallback은 언제 써야 할까 빠른 답 리렌더링은 React의 정상 동작입니다. 먼저 React DevTools Profiler나 Profiler API로 느린 컴포넌트와 상호작용을 확인하는 편이 좋습니다. memo 는 부모가 자주 렌더링되지만 자식의 props 가 자주 같게 유지되는 경우에 효과가 있습니다. useMemo 는 비싼 계산 결과를 캐시할 때, useCallback 은 함수 참조 변화가 자식 리렌더링이나 Effect 재실행으로 이어질 때 씁니다. 메모이제이션에도 비교 비용, 메모리 비용, 의존성 관리 비용이 있으므로 모든 값과 함수에 붙이는 방식은 대체로 이득이 작습니다. 목차 선택 기준 매트릭스 React 리렌더링 흐름 문제가 되는 리렌더링 현재 기준과 오래된 설명의 차이 상태 소유권부터 정리하기 자식 컴포넌트 리렌더링 줄이기 린트와 구성 기준 Profiler로 병목 확인하기 흔한 오해와 주의사항 선택 기준 매트릭스 상황 부모만 자주 바뀌고 자식 props 는 그대로라면 memo 로 자식 렌더링을 건너뛸 수 있습니다. 상황 큰 배열 필터링, 정렬, 집계처럼 렌더 중 계산이 무겁다면 useMemo 로 계산 결과를 재사용합니다. 상황 memo 로 감싼 자식에게 콜백을 넘기는데 함수 참조가 매번 바뀐다면 useCallback 을 고려합니다. 조건 객체, 배열, 함수가 매 렌더마다 새로 만들어진다면 props 형태를 줄이거나 참조를 안정화해야 memo 가 의미를 가집니다. 조건 입력값, hover, 모달 열림 같은 일시적 UI 상태가 너무 위에 있다면 메모이제이션보다 상태 위치 조정과 컴포넌트 분리가 먼저입니다. 상황 React Compiler를 도입한 환경이라면 수동 메모이제이션 필요성이 줄 수 있지만, 빌드 설정과 지원 범위를 먼저 확인해야 합니다. React 리렌더링 흐름 React 컴포넌트는 state , props , context 가 바뀌면 다시...

React render phase와 commit phase, 리렌더링이 DOM에 반영되기까지 빠른 답 render phase는 무엇이 바뀌어야 하는지 계산하는 단계라서 다시 실행되거나 중단될 수 있습니다. commit phase는 계산 결과를 실제 DOM에 반영하는 단계라서 짧고 일관되게 끝나는 것이 중요합니다. DOM 접근, 측정, 외부 부수효과는 render가 아니라 commit 이후 훅에서 처리해야 안전합니다. React 18 이후에는 render가 곧바로 화면 반영으로 이어진다고 보면 동작을 잘못 이해하기 쉽습니다. 목차 한눈에 비교 흐름으로 보기 왜 render phase와 commit phase를 자주 헷갈릴까 상태 변경부터 화면 반영까지 따라가기 실수를 빨리 잡는 설정 render에 둘 코드와 commit 이후에 둘 코드 로그로 보는 실행 순서 React 19.2 기준에서 달라진 설명 흔한 안티패턴과 디버깅 체크포인트 한눈에 비교 render phase : 컴포넌트를 호출해 다음 UI 스냅샷을 계산하는 단계입니다. 같은 입력이면 같은 출력이 나와야 하는 순수 계산이어야 합니다. commit phase : render 결과를 실제 DOM에 반영하는 단계입니다. ref 연결, DOM mutation, effect 실행 준비가 여기서 이어집니다. useLayoutEffect : commit 직후, 브라우저가 그리기 전에 실행됩니다. DOM 크기 측정이나 위치 보정처럼 paint 전에 끝나야 하는 작업에 맞습니다. useEffect : 외부 시스템과 동기화하는 용도입니다. 보통은 paint 뒤에 실행되지만, 사용자 상호작용으로 시작된 업데이트에서는 paint 전에 관찰될 수도 있습니다. 실무 기준으로는 파생값 계산은 render, DOM 측정은 useLayoutEffect , 네트워크·구독·타이머·로그 수집은 useEffect 로 나누면 거의 틀리지 않습니다. 흐름으로 보기 React 공식 문서는 이 과정을 trigger ...

React props와 state 차이, 언제 무엇을 써야 할까 빠른 답 props는 부모가 자식에게 내려주는 읽기 전용 데이터다. state는 컴포넌트가 직접 관리하며 바뀌면 화면이 다시 렌더링된다. 자식이 값을 바꿔야 하면 props를 수정하지 말고 부모의 state 변경 함수를 전달한다. 입력값, 로딩 여부, 토글 같은 변하는 UI 데이터는 대부분 state로 관리한다. 목차 props와 state가 처음 React에서 가장 헷갈리는 이유 한눈에 비교 props를 써야 하는 상황 state를 써야 하는 상황 예제를 위한 최소 구성 실전 코드로 보기: 부모의 state를 자식에 props로 전달하기 자주 하는 실수와 예외 케이스 실무 선택 기준: 어디에 둬야 하는가 props와 state가 처음 React에서 가장 헷갈리는 이유 React를 처음 배우면 props 와 state 가 비슷해 보입니다. 둘 다 JSX 안에서 값을 출력할 때 사용하고, 둘 다 화면 결과에 영향을 주기 때문입니다. 그래서 “둘 다 데이터면 그냥 아무 데나 넣어도 되는 것 아닌가?”라는 생각이 들기 쉽습니다. 하지만 둘의 차이는 문법보다 소유권 에 있습니다. 어떤 값을 부모가 가지고 자식에게 전달 하면 props 이고, 어떤 값을 컴포넌트가 자기 내부에서 직접 관리 하면 state 입니다. 이 기준만 분명히 잡히면, 어디에 어떤 값을 둬야 하는지 대부분 정리됩니다. 초보자가 가장 자주 막히는 지점도 여기입니다. 자식 컴포넌트에서 버튼을 눌렀는데 부모가 넘겨준 값을 바꾸고 싶을 때, props 를 직접 수정하려고 시도합니다. 하지만 React는 단방향 데이터 흐름을 전제로 설계되어 있어서, 값의 변경은 값을 소유한 쪽에서 일어나야 합니다. 자식은 값을 바꾸는 대신, “이 값을 바꿔 달라”는 요청을 부모에게 보내는 구조를 사용합니다. 한눈에 비교 비교형으로 정리하면 props 와 state 의 역할 차이가 더 빨리 보입니다. 소유자: props 는 부모가 소유...