-
Notifications
You must be signed in to change notification settings - Fork 47
[1팀 김민석] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계 #24
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
Open
kju1018
wants to merge
49
commits into
hanghae-plus:main
Choose a base branch
from
kju1018:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- setValue에서 storeValue 직접 참조하던 문제 수정 - React의 setState에 함수를 직접 전달하여 최신 state 보장 - 불필요한 함수형 업데이트 수동 처리 제거
- 도메인 카드(CouponCard)와 UI Card 컴포넌트 구조 분리 - useCouponForm 추가
- CartItemList 컴포넌트 추가 - OrderCouponSection 컴포넌트 추가 - OrderSummary 컴포넌트 추가
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
과제의 핵심취지
advanced: https://kju1018.github.io/front_7th_chapter3-2/
과제에서 꼭 알아가길 바라는 점
기본과제
Component에서 비즈니스 로직을 분리하기
비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기
뷰데이터와 엔티티데이터의 분리에 대한 이해
entities -> features -> UI 계층에 대한 이해
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?
주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?
계산함수는 순수함수로 작성이 되었나요?
특정 Entitiy만 다루는 함수는 분리되어 있나요?
특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?
데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?
심화과제
이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.
어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.
Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.
Context나 Jotai를 사용해서 전역상태관리를 구축했나요?
전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?
도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?
전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?
과제 셀프회고
과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?
리팩토링 자체는 그동안 많이 해왔지만, 지금까지의 리팩토링은 주로 컴포넌트를 분리하거나 공통 코드를 정리하는 수준에 머물러 있었습니다.
하지만 이번 과제를 통해 진행한 리팩토링은 UI만 담당하는 컴포넌트 분리, 비즈니스 로직 분리 등 훨씬 더 깊게 고민해야 하는 요소들이 많았고, 단순히 컴포넌트를 쪼개는 것을 넘어서는 새로운 접근 방식을 배울 수 있어 좋았습니다.
아직 “이건 나눠야 한다 / 이건 굳이 나누지 않아도 된다”는 판단이 즉각적으로 되지는 않지만, 그래도 이번 경험을 통해 점점 감이 잡혀가고 있는 것 같습니다.
이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?
이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!
이번 과제에서 UI 컴포넌트는 UI만 담당하고 비즈니스 로직을 분리하는 작업을 직접 경험해보면서, 재직 중인 회사 프로젝트에도 이러한 방식을 적용해보고 싶다는 생각이 들었습니다.
현재 제가 담당하고 있는 프로젝트는 UI 상태와 엔티티를 다루는 상태가 뒤섞여 있어, 유지보수 과정에서 구조적 어려움이 종종 발생하기 때문입니다.
이번 과제를 계기로 더 깊이 공부해 나가면서, 실제 프로젝트에서도 엔티티 상태와 UI 상태를 명확하게 분리하는 구조를 도입해보고 싶습니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
1.basic 프로젝트에서는 selectedCoupon 상태가 cart와 함께 관리되고 있어서, 쿠폰을 삭제한 뒤 selectedCoupon을 초기화하는 과정에서 useCart의 clearSelectedCouponByCode를 useCoupons로 콜백 형태로 주입해 처리하는 구조를 사용했습니다.
하지만 selectedCoupon도 결국 coupon 도메인에 속할 수 있지않을까? 하는 생각과 useCoupons 내부에서 쿠폰 삭제 후 setSelectedCoupon으로 직접 관리하는 것이 더 자연스러울 수도 있다고 생각했습니다.
코치님께서는 이런 경우 어떤 구조로 분리하셨을지 궁금합니다.