1. UI를 컴포넌트 계층 구조로 나누기
어떤 것이 컴포넌트가 되어야 하는지..?
-> 함수나 객체를 만들 때 처럼 하면 된다
단일 책임 원칙을 갖는다
-> 한 컴포넌트가 하나의 책임을 가지고, 완전히 캡슐화 해야 함
컴포넌트가 커지게 되면 작은 하위 컴포넌트로 분리한다
- ProductTable(노란색): 예시 전체를 포괄
- SearchBar(파란색): 유저의 입력(user input)
- ProductTable(연두색): 유저의 입력(user input)을 기반으로
데이터 콜렉션(data collection)을 필터링 - ProductCategoryRow(하늘색): 각 카테고리(category)의 헤더
- ProductRow(빨강색): 각각의 제품(product)에 해당하는 행
ProductTable을 보면 'Name' 과 'Price' 레이블을 포함한 테이블 헤더만을 가진 컴포넌트는 없다
이 같은 경우, 데이터를 위한 독립된 컴포넌트를 생성할지 생성하지 않을지는 선택
이 예시에서는 ProductTable의 책임인 데이터 컬렉션(data collection)이 렌더링의 일부이기 때문에 ProductTable을 남겨두었다
그러나 이 헤더가 복잡해지면 (즉 정렬을 위한 기능을 추가하는 등)
ProductTableHeader컴포넌트를 만드는 것이 더 합리적이다
이제 목업에서 컴포넌트를 확인하였으므로 이를 계층 구조로 나열해봅시다. 모형의 다른 컴포넌트 내부에 나타나는 컴포넌트는 계층 구조의 자식으로 나타냅니다.
- FilterableProductTable
- SearchBar
- ProductTable
- ProductCategoryRow
- ProductRow
2. React로 정적인 버전 만들기
UI 렌더링은 되지만 아무 동작이 없는 정적 버전을 만들어
과정을 나누는 편이 좋다
다른 컴포넌트를 재사용하는 컴포넌트를 만든 후 props 를 이용해 데이터를 전달해준다
정적 버전이기 때문에 state는 사용하지 않는다
간단한 버전은 하향식으로 개발하는 것이 편하지만
프로젝트 규모가 클수록 상향식으로 테스트를 작성하면서 개발하는 것이 쉽다
단방향 데이터 흐름 (단방향 바인딩)은 모든 것을 모듈화 하고 빠르게 만들어준다
3. UI state에 최소한의 표현 찾기
UI를 상호작용하게 만들기 위해 state를 사용한다
애플리케이션에서 필요로 하는 state의 최소 집합을 생각해봐야 한다
핵심은 중복 배제 원칙
나머지는 필요에 따라 계산되도록 한다
예를 들어 TODO 리스트를 만든다고 하면,
TODO 아이템을 저장하는 배열만 유지하고
TODO 아이템의 개수를 표현하는 state를 별도로 만들지 마세요.
TODO 갯수를 렌더링해야한다면 TODO 아이템 배열의 길이를 가져오면 됩니다.어떤 값이 state가 되어야 할까
1. 부모로부터 props를 통해 전달됩니까? 그러면 확실히 state가 아닙니다.
2. 시간이 지나도 변하지 않나요? 그러면 확실히 state가 아닙니다.
3. 컴포넌트 안의 다른 state나 props를 가지고 계산 가능한가요? 그렇다면 state가 아닙니다.4. state의 적절한 위치 찾기
어떤 state를 사용해야 하는지 찾았다면
어떤 컴포넌트가 해당 state를 소유할지 찾아야 한다
- state를 기반으로 렌더링하는 모든 컴포넌트를 찾으세요.
- 공통 소유 컴포넌트 (common owner component)를 찾으세요.
(계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트).
- 공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 합니다.
- state를 소유할 적절한 컴포넌트를 찾지 못하였다면,
state를 소유하는 컴포넌트를 하나 만들어서 공통 소유 컴포넌트의 상위 계층에 추가하세요.5. 역방향 데이터 흐름 추가하기
상태 끌어올리기
양방향 데이터 바인딩(two-way data binding)과 비교하면 더 많은 타이핑을 필요로 하지만
데이터 흐름을 명시적으로 보이게 만들어서 프로그램이 어떻게 동작하는지 파악할 수 있게 도와준다
setState() 를 아래로 전달해서 상태를 상위 컴포넌트로 전달할 수 있게 한다
모듈화되고 명시적인 코드는 읽을 때 조금 덜 어렵습니다.
큰 컴포넌트 라이브러리를 만들게 되면 이 명시성과 모듈성에 감사할 것이며
코드 재사용성을 통해 코드 라인이 줄어들기 시작할 것입니다. :)