3월 29일 공부일기 # 2

이건우·2021년 3월 29일
0

TiL

목록 보기
16/72

React로 사고하기를 새로, 정확하게 정리한 시간을 가졌다.
리액트에 대해 전체적인 틀이 눈에 들어오기 시작한듯 싶다.

크게 다섯단계로 나뉘어지는데

1단계

1단계는 컴포넌트 계층구조를 구상하는것이다 . (목업을 바탕으로)

2단계

2단계는 컴포넌트 계층을 직접 만든다. 여기서 주목해야할점은 아래에서 위로의 '상향식' 프로그래밍
기법이 쉽고 , 공식문서의 예를들면

 * FilterableProductTable
	* SearchBar
	* ProductTable
		ProductCategoryRow
		ProductRow

이런 순서대로 맨 아래의
'ProductCategoryRow'와 'ProductRow' 부터 스크립트를 작성한다. 아래와같이 작성

class ProductCategoryRow extends React.Component {
 render() {
   const category = this.props.category;
   return (
     <tr>
       <th colSpan="2">
         {category}
       </th>
     </tr>
   );
 }
}

class ProductRow extends React.Component {
 render() {
   const product = this.props.product;
   const name = product.stocked ?
     product.name :
     <span style={{color: 'red'}}>
       {product.name}
     </span>;

   return (
     <tr>
       <td>{name}</td>
       <td>{product.price}</td>
     </tr>
   );
 }
}

그다음 계층구조로 들어올 'Product table'과 'Searchbar'를 작성해주고 맨 마지막 하단에
최상위 컴포넌트를 작성해준다. 확실히 아래에서 위로 작성하는 방향이 작성하기 쉬운듯하다.

3단계

어플리케이션내의 데이터들은 다음과 같다 .

1) 제품의 원본목록
2) 유저가 입력한 검색어
3) 체크박스의 값
4) 필터링된 제품들의 목록

3번째 단계는 다시 state가 어떻가 들어가야할지 구상하는건데 조건은 3가지가 있다.

1) 부모로 부터 props를 통해 전달될까? -> 'state가 확실히 아님'
2) 시간이 지나도 변하지않을까? 'state가 확실히 아님 '
3) 컴포넌트 안 다른 state와 props를 가지고 계산 가능할까 ? 'state가 확실히 아님'

결론
'1)' 의 제품 원본목록은 props를 통해 전달되므로 state가 아님.
'2)'의 검색어와 체크박스는 state로 볼 수도 있는데, 시간이 지남에 따라 변하기도함.
다른것들로부터 계산할수가 없기때문임.

'4)' 필터링된 목록은 state가 아님. 제품원본 목록과 검색어 , 체크박스 값을 조합해서 계산가능.

결과적으로 애플리케이션은 '유저가 입력한 검색어'와 '체크박스의 값'이다.

4단계

state의 위치를 정해주기 . 어디가 좋을까 ?? 제일 어려운 부분이다.

1) state를 기반으로 렌더링 하는 모든 컴포넌트를 찾을것 (ex, 필터링)

2) 공통소유 컴포넌트를 찾을것 (모든 컴포넌트들의 상위에 있는 하나의 컴포넌트)

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

4) state를 소유할 적절한 컴포넌트를 찾지 못했다면, state를 소유하는 컴포넌트를
하나 만들어서 공통 오너 컴포넌트의 상위계층에 추가
ex) const twittler = [{}] 이 상위의 콘스트럭터 this에 넣은 좋은예인것이다.

5단계

**계층 구조 아래로 흐르는 props와 state 함수로써 앱을 만듬.
다른 방향으로 데이터 흐름을 만들어보자.

1) 계층구조 하단에 있는 폼 컴포넌트에서 FilterableProductTable 의 state를
업데이트 할 수 있어야한다.

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

3) 현재 상태에서 inputbox를 체크하거나 키보드를 타이핑할 경우, React가 입력을 무시
하는것을 확인가능함. 이것은 input 태그의 value 속성이 항상
FilterableProductTable에서 전달된 state와 동일하도록 설정했기 때문임.

want ?

1) 사용자가 폼을 변경할 때마다 사용자의 입력을 반영 할 수있도록 state를 업데이트 하는것

2) 컴포넌트는 그 자신의 state만 변경할 수 있기 때문에 FilterableProductTable은
SearchBar에 콜백을 넘겨서 state가 업데이트 되어야 할 때 마다 호출되도록함.

3) input에 onChange 이벤트를 사용해서 알림을 받을 수 있도록함.
FilterableTable에 전달된 콜백은 setState()를 호출하고 앱이 업데이트됨.

결론

React를 가지고 어플리케이션과 컴포넌트를 만드는데 대한 사고방식을 기르자.
이전보다 많은 타이핑을 해야 할 수도 있지만, 코드를 쓸 일보다 읽을일이 더많다.
모듈화되고 명시적인 코드는 읽을때 부담이 덜된다.
큰 컴포넌트 라이브러리를 만들게 되면 이 명시성과 모듈성에 감사하게 될것이며,
코드의 재사용성을 통해 라인이 줄어들것임.

profile
내가 느낌만알고 한줄도 설명할줄 모른다면 '모르는 것'이다.

0개의 댓글