- 리스트에서 key 속성을 주어야하는 이유?
key 속성은 배열을 렌더링했을 때 어떤 요소에 변동이 있었는지 알아내려고 사용한다. key가 없다면 가상돔과 비교하는 과정에서 리스트를 순차적으로 비교하면서 변화를 감지한다. 하지만 key가 있다면 이 값을 사용하여 어떤 변화가 일어났는지 더욱 빠르게 알아낼 수 있다.
리액트는 state에서 변경사항이 있는 부분만 캐치해서 리렌더링 해준다. 굳이 변경이 없는 데이터까지 DOM을 조작해서 불필요한 자원을 낭비하지 않겠다는 것이다. 만약 키가 있다면 배열에 추가된 요소만 리렌더링 한다.
- key는 어떤 값으로 주는 것이 좋은가?
key는 다른 항목들 사이에서 해당 항목을 고유하게 식별할 수 있는 고윳값을 사용하는 것이 좋다. 고유한 값이 없을 때만 index 값을 key로 사용하는데 index를 key로 사용하면 배열이 변경될 때 효율적으로 리렌더링하지 못한다. 따라서 대부분의 경우 ID를 key로 사용한다.
만약 리스트 항목에 명시적으로 key를 지정하지 않으면 React는 기본적으로 인덱스를 key로 사용한다.
key는 배열 안에서 고유해야 하고, 전체 범위에서 고유해야할 필요는 없다. 두 개의 다른 배열을 만들 때 동일한 key를 사용할 수 있다.
- 제어 컴포넌트(controlled component)
React에 의해 값이 제어되는 입력 폼 엘리먼트, 제어 컴포넌트를 사용하면 input의 값은 항상 React state에 의해 결정된다. 코드를 조금 더 작성하지만, 다른 UI 엘리먼트에 input 값을 전달하거나 다른 이벤트 핸들러에서 값을 재설정할 수 있다.
<input type="text" value={this.state.value} onChange={this.handleChange} />- 상태 끌어올리기
React에서 상태를 공유하는 일은 그 값을 필요로 하는 컴포넌트 간의 가장 가까운 공통 조상으로 상태를 끌어올림으로써 해결할 수 있다. 새 값을 전달받은 컴포넌트는 모두 리렌더링되기 때문이다.
- React를 사용한 프로젝트 설계 방식
-
UI를 컴포넌트 계층 구조로 나누기(디자이너가 있다면 컴포넌트 이름은 이미 정해져 있을 수도 있다.)
⇒ 하나의 컴포넌트는 한 가지 일만 하는 것이 이상적! (단일 책임 원칙)
-
React로 정적인 버전 만들기
-
UI 상태 추출하기
-
상태가 어디에 있어야 할지 생각하기
-
역방향 데이터 흐름 추가하기
