https://ko.react.dev/learn/thinking-in-react
정리하자면,,,
State 는 어떤걸로?
- 시간이 지나면서 변할 수 있음
- props로 받는거 아님
- 계산 가능 아님 ( vue에서 computed 에 들어가는건 아님.. 이렇게 이해)
State 어디에 위치?
- 공통부모
- 공통부모가 없다면 그 상위
- 아니면 새로 상위 컴포넌트 만들어서
더보기
이 중 어떤 게 State가 되어야 할까요? 아래의 세 가지 질문을 통해 결정할 수 있습니다.
- 시간이 지나도 변하지 않나요? 그러면 확실히 State가 아닙니다.
- 부모로부터 Props를 통해 전달됩니까? 그러면 확실히 State가 아닙니다.
- 컴포넌트 안의 다른 State나 Props를 가지고 계산 가능한가요? 그렇다면 절대로 State가 아닙니다!
그 외 남는 건 아마 State일 겁니다.
- 제품의 원본 목록은 Props로 전달되었기 때문에 State가 아닙니다.
- 사용자가 입력한 검색어는 시간에 따라 변하고, 다른 요소로부터 계산할 수 없기 때문에 State로 볼 수 있습니다.
- 체크박스의 값은 시간에 따라 바뀌고 다른 요소로부터 계산할 수 없기 때문에 State로 볼 수 있습니다.
- 필터링된 제품 목록은 원본 제품 목록을 받아서 검색어와 체크박스의 값에 따라 계산할 수 있으므로, 이는 State가 아닙니다.
따라서, 검색어와 체크박스의 값만이 State입니다! 잘하셨습니다! → 이걸보면 입력값을 state로 두면 되려나...?
State가 어디에 위치해야 하는지 결정
대개, 공통 부모에 State를 그냥 두면 됩니다.
혹은, 공통 부모 상위 컴포넌트에 둬도 됩니다.
State를 소유할 적절한 컴포넌트를 찾지 못했다면, State를 소유하는 컴포넌트를 하나 만들어서 상위 계층에 추가하세요.
Props vs State
React는 Props와 State라는 두 개의 데이터 “모델”이 존재합니다. 둘의 성격은 매우 다릅니다.
- Props는 함수를 통해 전달되는 인자 같은 성격을 가집니다. Props는 부모 컴포넌트로부터 자식 컴포넌트로 데이터를 넘겨서 외관을 커스터마이징하게 해줍니다. 예를 들어, Form은 color라는 Prop을 Button으로 보내서 Button을 내가 원하는 형태로 커스터마이징할 수 있습니다.
- State는 컴포넌트의 메모리 같은 성격을 가집니다. State는 컴포넌트가 몇몇 정보를 계속 따라갈 수 있게 해주고 변화하면서 상호작용Interaction을 만들어 냅니다. 예를 들어, Button은 isHovered라는 State를 따라갈 것입니다.
- Props와 State는 다르지만, 함께 동작합니다. State는 보통 부모 컴포넌트에 저장합니다. (그래서 부모 컴포넌트는 그 State를 변경할 수 있습니다.) 그리고 부모 컴포넌트는 State를 자식 컴포넌트에 Props로서 전달합니다. 처음 봤을 때 둘의 차이를 잘 알기 어려워도 괜찮습니다. 약간 연습이 필요할 거예요!
리렌더링?
- React는 다른부분만 리렌더링 → 최적화
- 모든 이벤트 핸들러가 실행되고 set 함수를 호출 한 후 화면 업데이트 → 단일 이벤트 중 여러번 리렌더링 방지
라이프사이클
- mount(생성): useEffect(() => { ... }, [])
- update(업데이트): useEffect(() => { ... }, [의존값])
- unmount(소멸): useEffect 반환 함수(return () => { ... })
import { useEffect } from "react";
function MyComponent() {
useEffect(() => {
// (생성/마운트 - created, mounted)
// 여기에 API 호출 등
console.log('컴포넌트가 마운트됨');
return () => {
// (언마운트 - destroyed)
// 이벤트 제거, 타이머 해제 등
console.log('컴포넌트가 소멸됨');
};
}, []); // 의존성 배열 - 빈 배열이면 최초/언마운트만 실행됨
return <div>Hello</div>;
}
JSX
https://ko.react.dev/learn/writing-markup-with-jsx
1.하나의 루트 엘리먼트로 반환하기
JSX는 HTML처럼 보이지만 내부적으로는 일반 JavaScript 객체로 변환됩니다.
하나의 배열로 감싸지 않은 하나의 함수에서는 두 개의 객체를 반환할 수 없습니다.
따라서 또 다른 태그나 Fragment로 감싸지 않으면 두 개의 JSX 태그를 반환할 수 없습니다.
2. 모든 태그는 닫아주기 (당연한거 아닌가..?)
3. 거의 대부분 캐멀 케이스로 작성
양방향 바인딩
vue에서 v-model 인것
import { useState } from "react";
function MyInput() {
const [text, setText] = useState('');
return (
<input
value={text}
onChange={e => setText(e.target.value)}
/>
);
}
리액티브 vs. 선언적, 불변성 관리
Vue
- Vue는 this.message = "hi"처럼 변경하면 자동으로 UI가 갱신
- 배열/객체 변화도 내부적으로 Proxy로 추적
React
- "불변성 유지"를 아주 중요하게 여김!
- 상태 변경 시 새로운 객체 생성 필요.
(기존 객체나 배열 수정 X, 꼭 새로운 레퍼런스 할당 O)
- 주요 이유: 레퍼런스가 달라져야 리렌더링이 발생함
- 객체도 마찬가지로 spread (...) 문법 등으로 새 객체를 만들어야 함.
즉, 상태(객체/배열) 변경 시 무조건 "복제 → 새롭게 할당" 방식이 기본!
// 잘못된 예시 (직접 수정)
const [arr, setArr] = useState([1,2,3]);
arr.push(4); // X (불변성 위배)
setArr(arr);
// 올바른 예시 (새 배열 할당)
setArr(prev => [...prev, 4]); // O
컴포넌트 통신
vue 에서는
- 부모 → 자식 props로 전달
- 자식 → 부모 $emit
React에서는
- 부모 → 자식 props로 전달
- 자식 → 부모 자식이 콜백 실행
- React는 emit과 같은 전용 시스템이 없습니다.
- 자식이 부모에게 데이터를 전달하려면, "부모가 함수(콜백)를 props로 주고, 자식이 그 함수를 호출"하는 방식입니다.
- 컴포넌트 간 state 이동은 props를 통해, cross-parent 간 이동은 상태 끌어올리기(lifting state) 방법을 자주 사용합니다.
import React, { useState } from 'react';
function Child({ msg, onMsg }) {
return (
<div>
<div>자식에서 받은 값: {msg}</div>
<button onClick={() => onMsg('자식에서 클릭됨!')}>
부모에 이벤트 알리기
</button>
</div>
);
}
function Parent() {
const [parentMsg] = useState('부모의 메시지!');
const handleChildMsg = (childMsg) => {
alert('자식에서 받은 메시지: ' + childMsg);
};
return (
<div>
<Child msg={parentMsg} onMsg={handleChildMsg} />
</div>
);
}
export default Parent;
상태관리
Vue
- Vuex (store, module, action/mutation 등)
React
- 복잡도/팀 규모에 따라 매우 다양함
- Context API: 간단한 전역상태 마치 Vue의 provide/inject 느낌
- 외부 라이브러리:
- Redux: 전통적, 정말 많은 기능(개발툴, 미들웨어)
- Recoil / Zustand: 간단한 글로벌 state
- MobX: 리액티브한 구조, 데코레이터 기반
상태 관리 패턴
- 기본적으로 "props-drilling"(여러 단계 props 전달)이 발생하면 Context나 외부 상태관리 사용 고려
- 작은 프로젝트 → useState/Context 조합으로도 충분
- 프로젝트가 커지면 Redux, Recoil, Zustand 등 사용 → 우리는 redux 사용
1. Context API
1) 개념
- React 공식 내장 기능(외부 라이브러리 불필요)
- 컴포넌트 트리 전체에서 전역적으로 데이터를 쉽게 공유
- 예: "로그인 정보, 테마, 언어" 등 여러 곳에서 반복적으로 쓰이는 값 관리에 적합
2) 원리
- createContext로 context를 생성
- Context.Provider로 값(value)을 하위 트리에 "공급(Provide)"
- 하위 컴포넌트 어디서든 useContext(Context)로 참조 가능
import { createContext, useContext, useState } from 'react';
const NameContext = createContext();
function App() {
const [name, setName] = useState('철수');
return (
<NameContext.Provider value={{ name, setName }}>
<Child />
</NameContext.Provider>
);
}
function Child() {
const { name, setName } = useContext(NameContext);
// 이렇게 중첩된 컴포넌트 어디서나 쉽게 접근
return <input value={name} onChange={e => setName(e.target.value)} />;
}
장점
- 별도 라이브러리 없이 전역 상태 가능
- 코드량 적음, 간단한 앱에 적합
단점
- 상태 변경 시 Provider 하위 모든 컴포넌트가 "무조건" 리렌더링됨 (성능 문제)
- 복잡한 전역 상태나 로딩/비동기 관리엔 한계
2. Redux
1) 개념
- React 중심의 가장 오래되고 유명한 상태 관리 라이브러리
- 아주 큰 앱(대규모 상태/데이터 흐름, 복잡한 데이터 구조, 액션 추적, 미들웨어 필요 등)에 특화
- 상태의 일관성, 예측가능성, 시간여행(debugging) 보장
2) 원리
- 메인 구성요소
- 상태(state)를 담고있는 중앙 저장소(하나만 존재)
2. action (액션)
- "이런 일이 일어났다!"라는 신호(객체/함수)
- { type: 'INCREMENT', payload: 3 } 처럼 객체
3. reducer (리듀서)
- 스토어의 상태를 "어떻게 바꿀지" 결정하는 함수
- 이전 상태+액션 → 새 상태 반환 (상태를 직접 바꾸지 않고, "복사본 새로 만듦" ★불변성)
- 1. store (스토어)
- Redux 상태 변화 흐름
- 액션 발행(dispatch action)
- 사용자가 버튼 클릭 → "INCREMENT"라는 액션을 발생시키도록 코드가 dispatch
- 리듀서(reducer)가 호출됨
- 현재 상태와 액션을 인자로 받아 새로운 상태를 '리턴'
- 스토어(store)가 새 상태로 변경
- React 컴포넌트는 구독해 두었다가, 상태가 바뀌면 자동으로 리렌더링됨
장점
- 아주 안정적, 예측가능/디버깅 최상, 미들웨어 확장 쉬움
(로깅, API관리, 비동기 등 커스텀 작업풍부)
- 레거시 기업/대형서비스에서 매우 많이 사용
단점
- 코드량 많음/복잡(boilerplate), 작은 앱에 불필요하게 무거움
- 리듀서/액션/스토어/미들웨어 등 개념이 많아서 진입장벽 있음
