React 컴포넌트의 의존성
기능적 type 분류
props
({......}) =>
hooks
useSomething()
특징적 Feature 분류
스타일 : 컴포넌트의 CSS 스타일
로직 : 컴포넌트에 쓰이는 UI 조직에 필요한 커스텀 로직 ㅣ 커스텀 훅 형태로 작성
전역상태 : 현재 UI를 표현하기 위해서, 유저의 액션을 통해 초래된 상태
리모트 데이터 스키마(데이터를 담는 그릇) : API 서버에서 내려주는 데이터의 모양
내 코드 바깥 -> 리모트 데이터 스키마 **
페북이 만든 릴레이문서엔,
로딩 인디케이터를 표시하면서 -> 필요한 모든 데이터를 가져온 다음 -> 데이터를 사용할 수 있게 되면 전체 뷰를 렌더링 //
1) 로딩상태가 각 컴포넌트에 있어서 각각 로딩시켜서 드르륵 로딩하게 됨
2) 로딩상태를 전체에 줘서 한번에 짠!
React 컴포넌트의 숨은 의존성
ex)
컴포넌트에 정보 새로 추가하기리모트 데이터 : 컴포넌트의 Props 수정
React 컴포넌트 : 의 렌더링 부분 수정
숨은 의존성 : 의 Props 수정
의 useEffect Hook 수정
** 리모트 데이터 스키마의 숨은 의존성
루트 컴포넌트 -> 리모트 데이터 스키마
의존성 "함께두기" Co-locate
리팩토링 원칙 1.
비슷한 관심사라면 가까운 곳에 (스타일과 로직을 함께 두기)
한 컴포넌트가 너무 커지는게 걱정이 된다면 같은 폴더내에 다른 파일로 관리해보기
스타일, 로직 을 컴포넌트에 함께 두기
리모트 에디터 스키마
위에서는 ID만 받고, 모양(스키마)은 전역 상태에서 받자
- 루트컴포넌트 > 다른 컴포넌트 > 컴포넌트 로 props 를 전달받기 보다는
현 컴포넌트의 데이터를 데이터 저장소에 저장하고 나서 그 값만 불러오기
정규화 하기
리팩토링 원칙 2.
데이터를 ID 기반으로 정리하기
정규화된 데이터를 가지고 특정객체를 데이터 저장소로부터 쉽게 가져올 수 있음. -> 또 숨은 의존성 있음. 상위 모델에서 정확하게 알고 있어야함. (전역 ID = global ID가 있어야함: 도메인 내에서 유일성을 갖는 ID rocp)
... $yarn add normalizr :
global ID
컴포넌트 -> 데이터 저장소 -> API 서버
hooks를 활용해서
