리액트 컴포넌트의 의존성 - 스타일, ui 로직, 전역상태, 리모트 데이터 스키마(api에서 내려주는 데이터)
정보를 표현하는 리액트 컴포넌트의 숨은 의존성이란?
일반적인 Article 컴포넌트에 정보를 새로 추가한다면 루트 컴포넌트, 중간에 있는 컴포넌트들까지 필연적으로 수정하게 되는데, 이를 리모트 데이터 스키마의 숨은 의존성이라고 한다.
함께두기 - co-locate
비슷한 관심사라면 가까운 곳에. (같은 파일이나 폴더)
위의 리액트 컴포넌트 의존성 중에서 스타일, 로직 부분은 함께두기를 실천하기 쉽다.
리모트 데이터 스키마는? props로 데이터를 내려받는다면 루트 컴포넌트와 강한 의존성을 갖게된다.
props로 article 데이터를 모두 내려주지 말고, id값만 내려준 후 데이터가 필요한 컴포넌트에서 id값으로 데이터 저장소에 요청
데이터를 ID기반으로 정리하기 → 데이터 정규화 (normalizr 라이브러리 살펴보기)
글로벌 ID → 도메인 내에서 유일성을 갖는 ID 체계
useArticle이라는 훅으로 데이터를 가져오는 방식은 여전히 article이라는 의존성이 필요하다.
useNode라는 새로운 훅에서 파라미터로 Article타입의 성격을 포함한 파라미터를 주고 데이터를 받아오는 방식으로 의존성을 줄일 수 있다.
GOI → Global Object Identification : Global ID 기반으로 특정 객체를 가져올 수 있는 api
props naming
의존한다면 그대로 드러내자
interface Props {
user: {
name: string,
nickname: string,
totalFollowerCount: number,
lastActivityAt: Date
},
image: {
thumbnailUrl: string
}
}모델간의 연결 정보(Graph)를 그대로 드러낸 객체
한 컴포넌트에서 여러 모델의 데이터가 필요하다면 관심사의 분리가 필요하다는 의미일 수 있음. 이때는 의존하는 모델에 따라 컴포넌트를 분리하자
상위 컴포넌트에서 해당 객체의 모양을 맞춰줘야 하기 때문에 재사용하기 힘들 것 같다고 생각할 수 있다.
위에서 말한 전역 id만 props로 내려주고 데이터 저장소에서 데이터를 요청한다면 컴포넌트간 의존성을 느슨하게 만들 수 있음.
재사용하기
개발할 때 편리하기 위한 것보다 변경할 때 편리하기 위해
같은 ui지만 리모트 데이터 스키마가 다르다면 컴포넌트를 재사용해야 할까?
모델 기준으로 컴포넌트 분리하기
같은 모델을 의존하는 컴포넌트 : 재사용
다른 모델을 의존하는 컴포넌트 : 분리
graphQL, relay 좋다. 위에서 말한 네가지 원칙을 하도록 강제함
Loading Comments...