React로 사고하기
0.목업으로 시작하기
JSON API와 목업을 디자이너로부터 받는다
1단계: UI를 컴포넌트 계층 구조로 나누기
모든 컴포넌트(와 하위 컴포넌트)의 주변에 박스를 그리고 그 각각에 이름을 붙이는 것입니다.
cf. 디자이너의 Photoshop 레이어 이름이 React 컴포넌트의 이름이 될 수 있습니다.
컴포넌트 설정 방법
1)'단일 책임 원칙'
: 하나의 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙
: 하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 한다
2) JSON 데이터 사용 시 이에 맞게 만든다
- 데이터 모델이 적절하게 만들어졌다면, UI(컴포넌트 구조)가 잘 연결될 것입니다.
: UI와 데이터 모델이 같은 인포메이션 아키텍처(information architecture)를 가지는 경향이 있다
=> 각 컴포넌트가 데이터 모델의 한 조각을 나타내도록 분리해주세요.
이제 컴포넌트들을 계층 구조로 나열한다
2단계: React로 정적인 버전 만들기
데이터 모델을 가지고 UI를 렌더링은 되지만 아무 동작도 없는 버전을 만든다
다른 컴포넌트를 재사용하는 컴포넌트를 만들고 props 를 이용해 데이터를 전달해줍시다.
props는 부모가 자식에게 데이터를 넘겨줄 때 사용할 수 있는 방법입니다.
정적 버전을 만들기 위해 state를 사용하지 마세요. state는 오직 상호작용을 위해, 즉 시간이 지남에 따라 데이터가 바뀌는 것에 사용합니다. 우리는 앱의 정적 버전을 만들고 있기 때문에 지금은 필요하지 않습니다.
앱을 만드는 방법
1)하향식(top-down) : 상층부에 있는 컴포넌트 (즉 FilterableProductTable부터 시작하는 것)부터
2)상향식(bottom-up) : 하층부에 있는 컴포넌트 (ProductRow)부터
=> 간단한 예시에서는 보통 하향식으로 만드는 게 쉽지만
프로젝트가 커지면 상향식으로 만들고 테스트를 작성하면서 개발하기가 더 쉽습니다.
이 단계가 끝나면 데이터 렌더링을 위해 만들어진 재사용 가능한 컴포넌트들의 라이브러리를 가지게 됩니다.
현재는 앱의 정적 버전이기 때문에 컴포넌트는 render() 메서드만 가지고 있을 것입니다.
계층구조의 최상단 컴포넌트 (FilterableProductTable)는 prop으로 데이터 모델을 받습니다.
데이터 모델이 변경되면 ReactDOM.render()를 다시 호출해서 UI가 업데이트 됩니다.
UI가 어떻게 업데이트되고 어디에서 변경해야하는지 알 수 있습니다.
React의 단방향 데이터 흐름(one-way data flow) (또는 단방향 바인딩(one-way binding))는 모든 것을 모듈화 하고 빠르게 만들어줍니다.
cf. Props vs State
React에는 두 가지 데이터 “모델”인 props와 state가 있습니다.
props: 부모로부터 데이터 전달
state: 변하는 상태 관리
3단계: UI state에 대한 최소한의 (하지만 완전한) 표현 찾아내기
UI를 상호작용하게 만들려면 기반 데이터 모델을 변경할 수 있는 방법이 있어야 합니다. 이를 React는 state를 통해 변경합니다.
애플리케이션을 올바르게 만들기 위해서는 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보아야 합니다. 여기서 핵심은 중복배제원칙입니다. 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만드세요.
state 설정 방법
1)부모로부터 props를 통해 전달됩니까? 그러면 확실히 state가 아닙니다.
2)시간이 지나도 변하지 않나요? 그러면 확실히 state가 아닙니다.
3)컴포넌트 안의 다른 state나 props를 가지고 계산 가능한가요? 그렇다면 state가 아닙니다.
=> 전달받지 않고 시간이 지나면 변하고 계산 불가능한 것
4단계: State가 위치 설정
다음으로는 어떤 컴포넌트가 state를 변경하거나 소유할지 찾아야 합니다.
React는 항상 컴포넌트 계층구조를 따라 아래로 내려가는 단방향 데이터 흐름을 따릅니다.
1)애플리케이션이 가지는 각각의 state에 대해서 state를 기반으로 렌더링하는 모든 컴포넌트를 찾으세요.
ex. state변수가 number면 number를 사용하는 컴포넌트를 모두 찾는다
2) 공통 소유 컴포넌트 (common owner component)를 찾으세요.
(계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트).
공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 합니다.
3)state를 소유할 적절한 컴포넌트를 찾지 못하였다면, state를 소유하는 컴포넌트를 하나 만들어서 공통 오너 컴포넌트의 상위 계층에 추가하세요.
5단계: 역방향 데이터 흐름 추가하기
지금까지 우리는 계층 구조 아래로 흐르는 props와 state의 함수로써 앱을 만들었습니다. 이제 다른 방향의 데이터 흐름을 만들어볼 시간입니다.
4단계의 예시에서 체크하거나 키보드를 타이핑할 경우 React가 입력을 무시하는 것을 확인할 수 있습니다.
이는 input 태그의 value 속성이 항상 FilterableProductTable에서 전달된 state와 동일하도록 설정했기 때문입니다.
우리가 원하는 것이 무엇인지를 한번 생각해봅시다. 우리는 사용자가 폼을 변경할 때마다 사용자의 입력을 반영할 수 있도록 state를 업데이트하기를 원합니다. 컴포넌트는 그 자신의 state만 변경할 수 있기 때문에 FilterableProductTable는 SearchBar에 콜백을 넘겨서 state가 업데이트되어야 할 때마다 호출되도록 할 것입니다.
우리는 input에 onChange 이벤트를 사용해서 알림을 받을 수 있습니다. FilterableProductTable에서 전달된 콜백은 setState()를 호출하고 앱이 업데이트될 것입니다.
input의 value = {state변수}
그러므로 직접 변경을 하려고 하면 무시한다
그러므로 onChange 이벤트에 대한 핸들러를 SearchBar
state변수
this.state = {
filterText: '',
inStockOnly: false
};
input태그
value={this.props.filterText}
onChange={this.handleFilterTextChange}
handleFilterTextChange(filterText) {
this.setState({
filterText: filterText
});
}
//onChange에서 직접 value를 변경하는 것이 아니라 setState로 변경Side Effect란?
- 정의: "함수의 입력 외에도 함수의 결과에 영향을 미치는 요인"
- 상태를 다룰 때에 Side Effect는 주요 고려 대상이다
ex. 네트워크 요청, API 호출
React의 주요 개발 원칙 중 하나는 UI를 페이지 단위가 아닌 컴포넌트 단위로 보는 것입니다.
=> '컴포넌트 우선 개발 방식'
presentation component
API 요청이 없이도 이 컴포넌트는 작동되어야 합니다. 어떤 데이터가 들어오는지 상관하지 않고, 설사 데이터가 가짜 데이터라 할지라도 컴포넌트는 표현(presentation) 그 자체에 집중하는 것이죠!!
상태의 두가지 구분
1. 로컬 상태
: 특정 컴포넌트 안에서만 관리되는 상태
컴포넌트 내에서만 영향을 끼치는 상태
- 전역 상태
: 프로덕트 전체 혹은 여러 컴포넌트에서 관리되는 상태
다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태
=> 서로 다른 컴포넌트가 동일한 상태를 다룬다면 출처는 오직 한 곳 (전역 공간)
사본이 있을 경우 두 데이터는 서로 동기화하는 과정 필요하므로 한 곳에서만 상태를 저장하고 접근해야 한다
데이터 무결성을 위해 동일한 데이터는 항상 같은 곳에서 데이터를 가지고 온다
single source of truth!
ex. 다크모드, 언어, 히스토리
상태 관리 툴의 역할
- 전역 상태를 위한 저장소 제공
- props drilling 문제 해결
: 최상위 컴포넌트 - 하위 컴포넌트 사이 다른 컴포넌트를 통과하지 않고도 전달 가능
