React로 생각하기 (Feat. 공식문서)

- 리액트로 프로젝트를 구현하면서 state를 남발하는 요즘... 이게 맞는건가? 라는 찝찝함이 남아 공식문서의 'React로 생각하기' 파트를 다시 읽어보았다. 처음 배울 때도 이 챕터를 읽기는 했지만, 지금 읽으면 또 다를 것이 분명하기때문에 ㅋㅋㅋㅋ 다시 정독 ㄱ ㄱ ! 

 

- 요즘 단순히 구현만 짠! 해내면 되는게 아니고, 정확한 용법으로 기능들을 사용하고 코드를 짜는 것은 더 많은 공부와 노력을 들여야 하는 일임을 절실히 느낀다. 돌아가기만 하면 되는 코드를 짜고 만족하지 말자! 그리고 꼭 꼭 공식문서를 더 많이, 더 자주 읽자. 이에 기반해서 내가 제대로 코드를 짜고 있는지 점검하는 습관을 들이자!

 

이 문서 (구버전) 다.

 

1. UI를 컴포넌트 계층 구조로 나누기

- 모든 컴포넌트의 주변에 박스를 그리고 그 각각에 이름을 붙이자. 

- 어떤 것이 컴포넌트가 되어야 하나?  = "단일 책임 원칙" : 하나의 컴포넌트는 한 가지 일을 하는게 이상적이다.

 

 => 하나의 컴포넌트가 커지게 된다면, 보다 작은 하위 컴포넌트로 분리하자.

 => UI와 데이터 모델이 같은 information architecture를 가지는 경향이 있다. 각 컴포넌트가 데이터 모델의 한 조각을 나타내도록 분리하자. 

 

2. React로 정적인 버전 만들기

- state를 사용하지 마세요.

 

3. UI state에 대한 최소한의 (하지만 완전한) 표현 찾아내기

- 중복 배제 원칙 -> 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만들자

e.g. TODO 리스트 -> TODO 아이템을 저장하는 배열만 유지하고, TODO 아이템의 개수를 표현하는 state를 만들지 말 것. 개수 렌더링이 필요하다면 TODO 아이템 배열의 길이를 가져오면 된다. 

 

- 애플리케이션 내의 데이터를 나열해보고, 어떤 데이터가 state가 되어야 하는지 생각해보자.

1. 부모로부터 props를 통해 전달되는가? 

2. 시간이 지나도 변하지 않는가?

3. 컴포넌트 안의 다른 state나 props를 가지고 계산 가능한가?

 

4. state가 어디에 있어야 할 지 찾기

- 어떤 컴포넌트가 state를 변경하거나 소유해야 하는가?

- 리액트는 항상 컴포넌트 계층구조를 따라 아래로 내려가는 단방향 데이터 흐름이다. 어떤 컴포넌트가 어떤 state를 가져야 하는지 아래 과정을 따라 결정해보자.

1. state를 기반으로 렌더링하는 모든 컴포넌트를 찾기

2. 공통 소유 컴포넌트를 찾기 (계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트)

3. 공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 함

4. state를 소유할 적절한 컴포넌트를 찾지 못했다면, state를 소유하는 컴포넌트를 하나 만들어서 공통 소유 컴포넌트의 상위 계층에 추가하기

 

* React는 전통적인 양방향 데이터 바인딩과 비교하면 더 많은 타이핑을 필요로 하지만, 데이터 흐름을 명시적으로 보이게 만들어서 프로그램이 어떻게 동작하는지 파악할 수 있게 도와준다. 

* 코드를 쓸 일보다 읽을 일이 더 많다. 모듈화되고 명시적인 코드는 읽을 때 조금 덜 어렵다. 명시성과 모듈성을 잘 구현하자.