• 리액트 컴포넌트는 필요한 것들을 props와 hooks를 통해 전달 받을 수 있다.
  • 리액트 컴포넌트가 가진 의존성의 기능적 분류
• 컴포넌트에서 import로 가져오는 것들의 특징
  • 스타일
    • 스타일은 컴포넌트에 필요한 의존성
• 커스텀 로직
  • UI 조작에 필요한 커스텀 로직 ⇒ 커스텀 훅
• 전역 상태
  • 유저의 액션을 통해 초래된 클라이언트의 상태
• 리모트 데이터 스키마
  • 원격, 즉 api 서버에서 내려주는 데이터
  • api 서버에서 내려주는 Json 데이터의 내용 및 모양

비슷한 관심사라면 가까운 곳에 위치

• 어떤 부분을 수정할때 파일들이 멀어지면, 집중력이 분산하기 마련.
• 같은 파일안에 두거나 바로 옆에 둔다.

1. 스타일과 로직

<aside> 🔃 스타일과 로직은 함께 두기가 쉽게 가능할 것 같다.

</aside>

• css in js : 스타일이 컴포넌트 안에 존재, Co-location

  

  <aside> 🔃 로직과 스타일을 묶어두었다.

  </aside>

  <aside> 🔃 스타일과 로직의 수정이 필요하지 않는경우, 여러파일을 오가지 않아도 함께 수정할 수 있게 되었다!

  </aside>

  • 만약 한 컴포넌트의 크기가 너무 커진다면? 🧐

    <aside> 🔃 상위나 하위에 다른 폴더가 아닌 “같은 폴더” 내에 다른 파일로 분리하는 것을 권한다. - 당근맨

    </aside>

리모트 데이터 스키마와의 의존성 (Suspense로 데이터가 필요한 컴포넌트에서 fetching하는게 아닌갑다..)

• 서버로 부터, 특정 컴포넌트에 필요한 데이터가 전달되기 까지의 과정

  • 루트 컴포넌트 ⇒ 중간 컴포넌트 ⇒ 내 컴포넌트로 데이터 스키마를 props로 내려준다면?

  

  최하단의 컴포넌트와 루트 컴포넌트와의 강한 의존성이 생긴다.

위에서는 ID만 받고, 모양(데이터 스키마)는 전역상태에서 받자

• props를 통해 데이터 스키마가 아닌 ID를 받고, id를 바탕으로 데이터 저장소에서 id를 통해 데이터를 받아온다.

<aside> 🔃 의존성을 끊어 낼 수 있다고 하는데, 확실히 끊어낸게 맞을까? ⇒ 어쨌든 id를 props로 전달받으면서, 다른 컴포넌트들도 id에 대한 의존성이 생긴게 아닌가?

</aside>

<aside> 🔃 id를 내려받고, 그려줄 view는 부모에서 render props로 전달해 줄 수 있을까? 그렇다면 부모에서는 타입이 보장이 되는가??

</aside>

const Container({id} : {id : number}){
	// 특정 데이터 타입
	const items = useItem(id)
	
	return <>{
		items.map((item) => <ArticleList item={}/>)
	}</>
}