앱의 디자인을 보면 ⇒ 컴포넌트를 찾아서 조립해나가야 함 ⇒ 컴포넌트 계층 구조로 나눠야함 ⇒ (상향식 앱 만들기)
단일 책임 원칙 (하나의 컴포넌트는 한가지 일만 한다)
데이터를 어디에 둘 것인가
props : 컴포넌트는 컴포넌트 바깥에서 props를 이용해 데이터를 전달인자 혹은 속성처럼 전달받을 수 있다 ⇒ 즉 데이터 전달주체는 부모 컴포넌트 ⇒ 데이터의 흐름은 하향식!(top-down) ⇒ 단방향 데이터 흐름! (핵심) ⇒ 컴포넌트는 props를 통해 전달받은 데이터가 어디서 왔는지 알수 없음
state
어떤 데이터를 상태로 두어야 하는지 여부 판단
부모로부터 props를 통해 전달 되는가? ⇒ state 아님
시간이 지나도 변하지 않는가? ⇒ state 아님
컴포넌트 안의 다른 states나 props를 가지고 계산 가능? ⇒ state 아님
상태를 어디에 두어야 하는지
특정 컴포넌트에서만 유의미 ⇒ 그 컴포넌트에 두면 됨
두 컴포넌트가 영향을 받는 경우 ⇒ 공통 소유 컴포넌트를 찾아 거기에 상태를 위치시킴 ⇒ 즉, 두 개의 자식 컴포넌트가 하나의 상태에 접근하고자 할 때 두 자식의 공통 부모 컴포넌트에 상태를 위치해야 함
역방향 데이터 흐름
부모 컴포넌트에서의 상태가 하위 컴포넌트에 의해 변하는 것 (ex. 새로운 트윗 추가로 부모에서 전체 트윗 목록 상태가 변화됨)
상태 끌어올리기(state lifting up)
⇒ 데이터의 변경사항을 상위 컴포넌트로 전달
⇒ state 갱신 함수를 전달받아 해당함수를 실행시키는 원리
⇒ 상태를 변경시키는 함수(handler)를 하위 컴포넌트에 props로 전달, 콜백함수 사용법과 비슷
⇒ 즉, 상위 컴포넌트의 "상태를 변경하는 함수" 그 자체를 하위 컴포넌트로 전달하고, 이 함수를 하위 컴포넌트가 실행 (단방향 데이터(props) 흐름 원칙에 부합)
(왜? 순수함수를 최대한 지키도록 하기 위해서 단방향 데이터 흐름으로 의도적으로 설계한 것)
⇒ 하위 컴포넌트는 상위 컴포넌트로부터 전달받은 데이터의 형태 혹은 타입이 무엇인지만 알 수 있음
⇒ 데이터가 state로부터 왔는지, 하드코딩으로 입력한 내용인지는 알지 못함