React관점에서 컴포넌트 톺아보기

Bewell·2023년 9월 4일
1
post-thumbnail

React 컴포넌트 구성할때 고려할 점

참고링크

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

2. 정적인 UI 만들기

  • 이벤트핸들러 추가하지 않고 정적 데이터로 UI 렌더링하는 버전을 먼저 만들자 (state만들지 말고 props로만 구성)
  • 하향식 : 상위->하위 : 간단한 예시에 좋고
  • 상향식 : 하위->상위 : 대규모 프로젝트에 좋다

3. 최소한의 완전한 UI State찾기

  • state 구조화

    • Don't Repeat Yourself
  • 최소한의 변화하는 데이터 집합으로 생각하기

  • 최소한의 state를 파악하고, 외의 모든 값은 필요할때 계산하자

  • state가 되는 조건

    1. 시간이 지나도 변하나요?
    2. 부모로부터 props를 통해 전달이 안되나요?
    3. 컴포넌트의 기존 state또는 props를 가지고 계산할 수 없나요?

    위 1,2,3질문에 YES의 값은 state로 생성한다

4. state가 어디있어야 할지 파악하기

  • React는 부모 -> 자식 컴퍼넌트로 아래로 내려가는 단방향 데이터 흐름이기 때문에 state를 소유하는 컴포넌트를 잘 식별해야한다

5. 역방향 데이터 흐름 추가하기



















지속가능한 컴포넌트 (feat. 변경에 유연한.)

참고링크

1. Headless 기반의 추상화

  • 데이터 추상화
    예를 들어 달력 컴포넌트를 구성한다고 가정하면 달력UI와 변하지 않는 달력 데이터를 분리할 수 있다.
  • useCalendar와 같은 hook을 통해 데이터와 UI를 분리하자
  • UI를 관심사에서 분리하자

2. 한 가지 역할만 하기

  • 각 컴포넌트는 서로의 존재를 모르고, 서로의 변경사항이 서로에게 영향을 끼치지 않아야 한다.
  • 합성 가능하도록 컴포넌트를 설계하면 재사용, 확장면에서 좋다

3. 도메인 분리하기

  • 도메인을 걷어내고 일반 표준의 인터페이스에 가까운 컴포넌트를 만들자
  • 도메인을 아는 컴포넌트와 도메인을 모르는 컴포넌트로 분리
  • 도메인을 아는 컴포넌트에서 비지니스 로직을 처리하고, UI로직은 위임하는 형태


















기존 Selector의 문제점

  1. props로 받는 option값을 state로 변환한 점
    • 이 때문에 리렌더링 시점을 명확하게 파악하기 어려움 (?)
  2. Headless 하지 않은 구조
    • UI와 데이터가 분리되어 있지 않음
      - UI와 hook으로 분리하여 데이터 추상화하자
    • 컴포넌트가 한가지 역할만 하고 있지 않음
      • 컴포넌트는 한가지 역할만 할 수 있도록 설계하자
  3. 다양한 Type
    • 'single' | 'multiple' | 'filterable' | 'suggest'
    • type별 동작이 각각 다양한데 처리에 대한 모듈화 안됨
      - 문제 발생시 리팩토링 어려움
      • 리팩토링하면서 다른 동작에 영향을 끼칠 확률 높아짐
  4. 사용자 interface관점에서 설계 부족

참고
1. React Rerendering에 관한 아주 자세하고, 중요한 내용 https://velog.io/@mogulist/understanding-react-rerender-easily
2. 어떻게 컴포넌트를 구성하고 설계할 것인가?
https://velog.io/@moreso/designing-complex-components-flexibly

0개의 댓글