React 개발 방식의 특징

리액트 개발 방식의 큰 특징은 페이지 단위가 아닌 "컴포넌트" 단위로 시작한다.

아래의 프로토타입을 전달 받았을 때

"컴포넌트"를 찾는다면?

이렇게 컴포넌트를 찾아 나눌 수 있다.

페이지를 만들기 이전 "컴포넌트"를 먼저 만들어 하나씩 조립해 나가는 것을 알 수 있다.
즉, 상향식(bottom-up)으로 앱을 만들며 상향식의 가장 큰 장점은 테스트가 쉽고 확장성이 좋다
bottom-up: 작은 것부터 하나씩 구현해서 전체를 만드는 방식이다.

아래와 같은 클론 트위터 앱이 있다고 가정했을 때 컴포넌트를 나누게 된다면

위 같은 형식으로 컴포넌트를 나눌 수 있다.

why? 이렇게 나누었을까

단일 책임 원칙에 따른 구분이며 "하나의 컴포넌트는 한 가지 일만 한다"

컴포넌트를 트리 구조로 생각해보자

컴포넌트를 나누었으니 트리구조로 보았을 때 해당 구조에서 "데이터"를 어디에 넣을 지 생각해야 한다.

데이터는 위에서 -> 아래로 흐르고 있다.

컴포넌트는 컴포넌트 바깥에서 props를 이용해 데이터를 마치 전달인자(arguments) 혹은 속성(attributes)처럼 전달받을 수 있다.

따라서, 데이터를 전달해주는 Tweets가 "부모 컴포넌트"가 되며 이 흐름은 top-down, 하향식을 의미한다.
top-down: 큰 문제를 해결하기 위해 작은 문제를 호출한다는 의미

단방향 데이터 흐름(One-way data flow)

단방향 데이터 흐름 단방향 데이터 흐름(UDF)은 상태는 아래로 이동하고 이벤트는 위로 이동하는 디자인 패턴입니다. 단방향 데이터 흐름을 따라 UI에 상태를 표시하는 컴포저블과 상태를 저장하고 변경하는 앱 부분을 서로 분리할 수 있습니다.

리액트는 단방향 데이터 흐름을 따른다.

데이터의 정의

state 상태?

우선 Twittler 애플리케이션이 갖고 있는 상태를 알아보자.
1. 전체 트윗 목록
2. 사용자가 작성 중인 새로운 트윗 목록

위 중 변하는 값과 변하지 않는 값은 무엇일까?
사용자가 작성 중인, 사용자 입력은 "이벤트"에 따라서 얼마든지 값이 변할 수 있다. 이것을 상태(state)라고 한다

또 트윗 목록이 추가 또는 삭제될 여지가 없다면 state로 둘 필요가 없다 하지만! 트윗 추가라는 기능을 염두하고 있기 때문에 변할 수 있는 값이 될 수 있으므로 트윗 목록 역시나 상태(state)가 된다.

상태가 많아질 수록 애플리케이션은 복잡해지므로 주의한다.

상태의 위치

상태가 특정 컴포넌트에만 유의미한 경우 해당 컴포넌트에만 두면 되니 어렵지는 않다, 다만 하나의 상태를 기반으로 두 개의 컴포넌트가 영향을 받는다면 공통 소유 컴포넌트를 찾아 그곳에 상태를 위치시켜야 한다.

이렇게 두 개의 자식 컴포넌트가 하나의 상태에 접근하고자 할 경우 두 자식을 "공통 부모 컴포넌트"에 상태를 위치 시킨다.