0716

ㅈㅉ 어렵다.
너무 어렵다.
ㅋㅋㅠ

clone coding

• 어제 오늘 이 글을 읽고 디렉토리 구조에 대해서 다시 생각해봄.

• 특정 방법론을 따라간다기 보다는, 디렉토리 구조를 정하는 것의 목표 자체가 코드가 어딨는지 빠르게 찾기 위해서 라고 생각함.

• 고로 눈에 보기 좋게 디렉토리 구조를 짜려고 노력함..

• 도메인

  • 비즈니스에서 다루는 개념적인 영역
  • 쇼핑몰로 따지면 "제품", "사용자", "주문", "장바구니" 가 있음

• 프레젠터

  • 오로지 순수하게 UI만 담당하는 것

• 컨테이너

  • 로직을 담당

했던 생각들 ...

1. (deal)은 제품 안에서도 할인 상품에 속하니까 product의 하위 디렉토리로 들어가는게 맞지 않을까?
   • 근데 이렇게 했을 때의 문제점이 기존에 [id] 의 컴포넌트를 product의 바로 하위 디렉토리에서 관리하고 있었어서 구조를 봤을 때 한 눈에 와닿는게 없는 느낌(?)이 들었음
   • 그래서 상세 페이지 관련 된 components랑 hook은 [id] 디렉토리 안에 둠

- app
	- _shared
		- components
		- hooks
		- providers
		- stores
	- (point)
		- components
		- stores
		- hooks
	- cart
		- components
		- stores
		- hooks
	- product
		- [id]
			- components
			- hooks
			- page.tsx
		- (deal)
			- components
			- hooks
		- components
		- hooks
	- layout
	- page

2. 어떤건 product list고 어떤건 card고 일관성이 없지 않나

   • 기존에 product personalized와 deal에서 쓰이는 컴포넌트가 겹치는게 많아
     공통 컴포넌트는 바로 product의 components에 두는 식으로 추상화함

3. 근데 컴포넌트를 분리(추상화)하다보니
   폼(옵션, 수량)과 디테일의 컴포넌트가 혼잡되어서 복잡하단 생각이 듦

- app
	- product
		- [id]
			- components
				- AddToCartForm     // 상세 페이지의 폼
				- ProductDescription// 상세 페이지
				- ProductDetailView // 상세 페이지
				- ProductOptions    // 상세 페이지의 폼
				- ProductOverView   // 상세 페이지
				- ProductQuantity   // 상세 페이지의 폼
				- ProductReivew     // 상세 페이지
				- ProductTab        // 상세 페이지
				- ProductTabContent // 상세 페이지

• 그래서 product/[id]/components에 forms를 만들었는데
  이러면 또 디렉토리 구조가 너무 깊어지는 감이 있는 것 같았음.
• 결론적으론 form 관련은 AddToCart~의 형태로 컴포넌트명을 바꿈.
  이러면 아 얘는 장바구니 들어갈 때 쓰이는 컴포넌트구나 라고 알 수 있으니까.

4. (point)는 어디에 두는게 맞는건가

   • 아직 point 관련 컴포넌트와 store는 제작하지 않았지만
     전역에서 관리되는 상태니까 app 바로 하위가 맞을 것 같음

5. import 경로 순서

   • hooks > componets > lib/utils, types > style이 좋을까
   • 아니면 lib/utils, types > style > hooks > components가 좋을까
   • 하위에서 상위로 가는 구조이기 때문에 후자의 방식을 채택함