React 컴포넌트의 의존성
- 기능적 분류: Props, Hooks 등
- 특징적 분류
- 스타일: 컴포넌트의 CSS 스타일
- 로직: UI 조작에 필요한 커스텀 로직
- 전역 상태: 현재 UI를 표현하기 위해 유저의 액션을 통해 초래된 클라이언트의 상태
- 리모트 데이터 스키마: API 서버에서 내려주는 데이터의 모양
- 루트 컴포넌트와 현재 컴포넌트 사이의 수많은 컴포넌트들
컴포넌트 리팩터링 원칙
1. 함께 두기 (CO-locate)
비슷한 관심사라면 가까운 곳에 (Keep Locality)
예) 스타일(CSS-in-JS)과 로직(Custom Hooks)을 컴포넌트 내부에 함께 두기
예) 위에서는 ID만 받고, 모양(스키마)은 전역 상태에서 받기
2. 데이터를 ID 기반으로 정리하기
정규화 (Normalization)
Global ID
도메인 내에서 유일성을 갖는 ID 체계. Node ID라고도 한다.
Global ID를 활용해,
사용할 데이터의 모델 정보마저 컴포넌트 내부에 Co-locate (의존성 줄이기)
GOI (Global Object Identification)
어떠한 코드 위치, 맥락에 있든 Global ID 기반으로 특정 객체를 가져올 수 있는 API
3. 의존한다면 그대로 드러내기 (Make Explicit)
의존하는 모델에 따라 컴포넌트를 분리하되, 연결 정보를 그대로 드러내기
4. 재사용하기 (Reuse)
컴포넌트를 재사용하는 이유는
개발할 때 편리하기 위한 것보다 변경할 때 편리하기 위함이다.
모델 기준으로 컴포넌트 분리하기 (Separating Components by Model)
겉모습의 유사성이 아니라, 리모트 데이터 스키마에 따라 컴포넌트를 만들어야 한다.
유저들이 느끼는 일관적인 경험은 대부분 모델을 기반으로 하기 때문에,
변화는 모델을 기준으로 정렬되어야 한다.
같은 모델을 의존하는 컴포넌트: 재사용
다른 모델을 의존하는 컴포넌트: 분리
결론
“질문이 정답보다 중요하다”
“관점이 기술보다 중요하다”
GraphQL, Relay
단지 최신 기술이라서 도입하는 것이 아니라, 유저 경험을 고려해야 한다.