기본 콘텐츠로 건너뛰기

라벨이 JavaScript인 게시물 표시

리액트 폼 입력은 누가 관리해야 할까: Controlled와 Uncontrolled 선택 기준

리액트 폼 입력은 누가 관리해야 할까: Controlled와 Uncontrolled 선택 기준 빠른 답 입력값이 화면 상태와 함께 즉시 바뀌어야 하면 Controlled가 기본 선택입니다. 제출할 때만 값을 읽으면 되는 단순 폼은 Uncontrolled가 더 간단합니다. 핵심 기준은 성능보다 데이터 흐름과 상태 소유권을 어디에 둘지입니다. value와 defaultValue를 섞거나 ref와 state를 함께 밀어붙이면 버그가 나기 쉽습니다. 목차 왜 두 방식이 자주 헷갈릴까 한눈에 비교 먼저 결정할 질문: 이 값은 화면 상태인가, 제출 데이터인가 Controlled Component가 맞는 상황 Uncontrolled Component가 맞는 상황 예외 케이스와 하이브리드 구성 흔한 안티패턴과 디버깅 포인트 실무 선택 기준 정리 왜 두 방식이 자주 헷갈릴까 겉으로 보면 둘 다 똑같이 입력창이 동작합니다. 사용자는 타이핑하고, 화면에는 글자가 보입니다. 그래서 처음에는 " useState 로 관리하든 ref 로 읽든 결과가 같은 것 아닌가?"라고 느끼기 쉽습니다. 하지만 실무에서 중요한 것은 누가 현재 값을 소유하느냐 입니다. Controlled Component 는 입력값의 원본이 리액트 state 입니다. 반대로 Uncontrolled Component 는 브라우저 DOM이 값을 들고 있고, 리액트는 제출 시점이나 특정 이벤트에서만 그 값을 읽습니다. 즉 차이는 문법이 아니라 데이터 흐름입니다. 입력값이 다른 UI를 바꾸는지, 부모 컴포넌트가 현재 값을 알아야 하는지, 입력 중간에 검증이나 자동 저장이 필요한지에 따라 선택이 갈립니다. 한눈에 비교 값의 출처: Controlled 는 state , Uncontrolled 는 DOM의 현재 값입니다. 데이터 흐름: Controlled 는 onChange -> setState -> render -> value 순서로 흐르고, Uncontrolled ...

React props와 state 차이, 언제 무엇을 써야 할까

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 는 부모가 소유...

자바스크립트 이벤트 루프, 실행 순서가 헷갈릴 때 바로 이해하는 방법

자바스크립트 이벤트 루프, 실행 순서가 헷갈릴 때 바로 이해하는 방법 목차 이벤트 루프가 필요한 이유 콜 스택, 태스크 큐, 마이크로태스크 큐를 분리해서 보기 실제로 어떤 순서로 실행되는가 실험 환경은 이렇게 준비하면 충분합니다 브라우저에서 실행 순서를 직접 확인해보기 Node.js에서는 무엇이 다를까 실무에서 자주 틀리는 포인트 실행 순서 버그를 잡는 가장 현실적인 방법 빠른 답 이벤트 루프는 콜 스택이 비었을 때 대기 중인 작업을 실행 순서에 맞게 넘겨주는 구조입니다. Promise.then, queueMicrotask는 보통 setTimeout보다 먼저 실행되며, 이유는 마이크로태스크가 더 높은 우선순위를 가지기 때문입니다. setTimeout(fn, 0)은 즉시 실행이 아니라 현재 동기 코드가 끝난 뒤 다음 턴으로 미루는 동작에 가깝습니다. 실행 순서 버그를 잡을 때는 콜 스택, 마이크로태스크, 매크로태스크를 분리해서 로그로 확인해야 합니다. 초안을 발행용 글로 다시 정리하고 있습니다. 빠른 답 을 짧게 다듬고, 브라우저·Node.js에서 바로 실행해 볼 수 있는 설정과 예제를 중심으로 본문을 재구성하겠습니다.# 자바스크립트 이벤트 루프, 실행 순서가 헷갈릴 때 바로 이해하는 방법 빠른 답 이벤트 루프는 콜 스택이 비는 시점마다 대기 중인 작업을 확인하고, 우선순위에 맞게 다시 실행 흐름에 올리는 런타임 메커니즘입니다. Promise.then , queueMicrotask , await 이후 코드는 보통 setTimeout(..., 0) 보다 먼저 실행됩니다. 이들은 마이크로태스크로 처리되기 때문입니다. setTimeout(fn, 0) 은 즉시 실행이 아니라 현재 동기 코드와 현재 턴의 마이크로태스크가 끝난 뒤 다음 태스크로 넘기는 예약에 가깝습니다. 실행 순서가 꼬일 때는 코드를 동기 , 마이크로태스크 , 매크로태스크 로 나눠 로그를 찍으면 원인을 가장 빨리 찾을 수 있습니다. 이벤트 루프가 필요한 이유 자바스크립트는 ...