-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4팀 장철희] [Chapter 2-2] 디자인 패턴과 함수형 프로그래밍 #47
base: main
Are you sure you want to change the base?
Conversation
getRemainingStock 외부 의존성 제거 cart util 함수 사용
컴포넌트는 ui에 대한 컴포넌트로 생각하고, EditProduct 폴더는 product를 수정하는 관심사로 생각하고 분리
Component separation
<h2 className="mb-4 text-2xl font-semibold">장바구니 내역</h2> | ||
<div className="space-y-2"> | ||
{cart.map(item => { | ||
return ( | ||
<CartItem | ||
key={item.product.id} | ||
cart={item} | ||
onQuantityUpdate={updateQuantity} | ||
onCartRemove={removeFromCart} | ||
/> | ||
); | ||
})} | ||
</div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
장바구니 내역(구폰적용, 주문요약)영역을 세션으로 컴포넌트 분리 할까 하다가 너무 뎁스가 깊어지는 것 같아서 작은 단위의 컴포넌트만 분리 하였는데, 세션 영역도 컴포넌트를 분리하는 것이 좋을까요?
const updateName = (name: string) => { | ||
updateValue('name', name); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
막상 useCouponForm hook을 만들고 보니 그냥 핸들러 상태로 있을 때와 크게 다르지 않은 것 같는 생각이 들었습니다.
const handleNameChange = (e) => {
updateValue('name', e.target.name);
};
이런 분리는 과한 분리겠죠..?
code clean
과제 체크포인트
기본과제
React의 hook 이해하기
함수형 프로그래밍에 대한 이해
Component에서 비즈니스 로직을 분리하기
비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
심화과제
뷰데이터와 엔티티데이터의 분리에 대한 이해
엔티티 -> 리파지토리 -> 유즈케이스 -> UI 계층에 대한 이해
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
특정 Entitiy만 다루는 함수는 분리되어 있나요?
특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?
데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?
단일 책임 원칙 (Single Responsibility Principle)
순수 함수 (Pure Functions)
합성 가능성 (Composability)
관심사 분리 (Separation of Concerns)
DRY (Don't Repeat Yourself) 원칙
테스트 용이성 (Testability)
(input에 대한 output을 정의하기 수월한가)
에러 처리 (Error Handling)
과제 셀프회고
fsd 구조로 해보려고 문서들을 읽어보기도 했는데, 읽을 때는 이해를 한 것 같았지만 실제로 적용을 해보려고 하니 이 파일을 어디에 두어야 하나.. 하는 감이 잘 안잡혔습니다.
시간이 너무 지체 될 것 같아서 롤백을 하였는데, 다음주에 fsd를 배울 수 있다고 하니 기대가 됩니다!
컴포넌트는 관심사와 유저의 행동을 기준으로 분리하고, 레벨이 같은 컴포넌트 단위로 묶어서 폴더 구조를 수정하였습니다.
ui는 디자인 시스템처럼 작은 단위의 ui를 생각하였습니다. (시간이 없어서 전반적으로 ui 컴포넌트를 생성하지는 못 했습니다)
과제에서 좋았던 부분
막연한 느낌과 경험으로 컴포넌트를 분리하던 것을 기능으로 분리한다는 정의가 세워진 것 같습니다.
custom hook과 state를 함께 컴포넌트에서 사용할 때가 있는데, 무언가 복잡해 보이던 것이 레이어 계층이 달라서 였을지도 모른다는 생각을 할 수 있게 되어 좋습니다. 컴포넌트를 나누는 기준을 좀 더 논리적으로 말 할 수 있을 것 같습니다.
전역 상태관리를 사용하지 않고 컴포넌트를 분리를 시도하였습니다. 전역 상태 관리에 익숙해져서 초반에는 분리를 어떻게 할지 고민이 많았는데 props로 관심사를 좁힌다는 생각으로 접근하니 조금 수월해졌던거 같습니다. (잘 분리 되었는지는 모르겠지만 😅)
과제를 하면서 새롭게 알게된 점
레이어 계층에 대한 개념과 컴포넌트를 나누는 기준이 조금 더 명확해졌습니다.
과제를 진행하면서 아직 애매하게 잘 모르겠다 하는 점, 혹은 뭔가 잘 안되서 아쉬운 것들
다음주에 fsd 개념을 꼭..
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문