[ ] 하나의 컴포넌트는 한 가지 일을 하는가?
[ ] 하나의 컴포넌트가 커지게 되어 보다 작은 하위 컴포넌트로 분리하였는가?
[ ] JSON 데이터를 불러왔을 때, 각 컴포넌트가 데이터 모델의 한 조각을 나타내도록 분리하였는가?
[ ] 데이터 모델을 가지고 UI를 렌더링은 되지만 아무 동작도 없는 버전을 만들어보았는가?
정적 버전을 만드는 것은 생각은 적게 필요하지만 타이핑은 많이 필요로 하고, 상호작용을 만드는 것은 생각은 많이 해야 하지만 타이핑은 적게 필요하므로 정적인 버전을 먼저 만들어보자
[ ] state는 오직 상호작용을 위해, 즉 시간이 지남에 따라 데이터가 바뀌는 것에 사용한다. 혹시 정적 버전을 만들기 위해 state를 사용하는 우를 범하였는가?
[ ] 하향식(top-down)과 상향식(bottom-up) 중 어떤 방향으로 컴포넌트를 만들 지 정하였는가?
간단한 예시에서는 보통 하향식으로 만드는 게 쉽지만 프로젝트가 커지면 상향식으로 만들고 테스트를 작성하면서 개발하기가 더 쉽다.
UI를 상호작용하게 만들려면 state를 통해 변경시켜라
[ ] 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보았는가?
핵심은 중복배제원칙! DRY!
[ ] 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때 그때 계산되도록 만들었는가?
TODO 리스트를 만든다고 하면, TODO 아이템을 저장하는 배열만 유지하고 TODO 아이템의 개수를 표현하는 state를 별도로 만들지 말자. TODO 갯수를 렌더링해야한다면 TODO 아이템 배열의 길이를 가져오면 되니까!
[ ] state를 기반으로 렌더링하는 모든 컴포넌트를 찾자.
[ ] 공통 소유 컴포넌트 (common owner component)를 찾자. (계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트).
[ ] 공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 한다.
[ ] state를 소유할 적절한 컴포넌트를 찾지 못하였다면, state를 소유하는 컴포넌트를 하나 만들어서 공통 오너 컴포넌트의 상위 계층에 추가하자.
[ ] 사용자가 폼을 변경할 때마다(check box, filtering something etc.) 사용자의 입력을 반영할 수 있도록 state를 업데이트할 수 있는가?
[ ] 콜백을 만들어 부모 요소의 state가 업데이트되어야 할 때마다 호출되도록 하였는가?