-
Notifications
You must be signed in to change notification settings - Fork 47
[2팀 이정민] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계 #34
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
LEE-jm96
wants to merge
38
commits into
hanghae-plus:main
Choose a base branch
from
LEE-jm96: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
useAdminPage, useCart, useCouponForm, useCoupons, useCouponValidation, useNotifications, useProductForm, useProducts, useSearch
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.
배포링크
basic: https://lee-jm96.github.io/front_7th_chapter3-2/index.basic.html
advanced: https://lee-jm96.github.io/front_7th_chapter3-2/index.advanced.html
과제의 핵심취지
과제에서 꼭 알아가길 바라는 점
기본과제
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는 잘 제거했나요?
전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?
과제 셀프회고
과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?
이번 과제를 통해 상태 관리의 두 가지 접근 방식을 깊이 비교해볼 수 있었습니다.
Basic 버전은 useState + 커스텀 훅으로 컴포넌트 내부에서 상태를 관리하지만, Props Drilling이 발생합니다.
Advanced 버전은 Jotai의 atom을 사용해 전역 상태를 관리하고, 필요한 컴포넌트에서 직접 구독하여 Props Drilling을 해결했습니다.
가장 큰 배움은 액션(Actions)과 순수 함수(Pure Functions)를 명확히 구분하는 것이었습니다.
순수 함수: cartCalculations.ts, validators.ts, formatters.ts - 테스트 가능하고 예측 가능
액션: idGenerator.ts - 시간에 의존하는 함수들을 명시적으로 분리
특히 처음에는 Date.now()나 new Date()를 atom이나 hook 내부에서 사용했는데, 이것이 테스트를 어렵게 만들고 순수성을 해친다는 것을 깨달았습니다. idGenerator.ts로 분리하니 각 함수의 책임이 명확해지고, 테스트 시 모킹하기도 쉬워졌습니다.
이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?
비즈니스 로직과 부수 효과의 명확한 분리에 가장 신경 썼습니다.
코드를 리팩토링하면서:
계산 로직 순수화: calculateCartTotal, getMaxApplicableDiscount 등의 계산 함수들이 외부 상태에 의존하지 않고 입력만으로 결과를 도출하도록 구현
ID 생성 로직 분리:
Before - atom 내부에서 시간 의존
id: p${Date.now()}After - 외부에서 주입
const id = generateProductId(); const product: Product = { ...newProduct, id };이렇게 분리하니 각 함수의 역할이 명확해지고, 나중에 유닛 테스트를 작성할 때도 훨씬 쉬울 것 같습니다.
이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!
지금은 함수형으로 깔끔하게 분리해놨으니, 다음 단계로 유닛 테스트를 작성해보고 싶습니다. 특히:
순수 함수들(cartCalculations.ts)은 입력-출력만 테스트
액션 함수들(idGenerator.ts)은 모킹하여 테스트
Jotai atoms의 상태 변화 테스트
Jotai의 atomFamily를 사용한 동적 atom 생성
Derived atoms를 더 활용한 복잡한 계산 로직
Suspense와 함께 비동기 상태 관리
React DevTools Profiler로 불필요한 리렌더링 찾기
useMemo, useCallback 최적화가 실제로 얼마나 효과적인지 측정
Jotai와 useState 성능 비교 실험
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
지금은 Date.now()를 사용하는 ID 생성 함수들을 모두 분리했는데, 실무에서는 어느 정도까지 분리하는 것이 적절한가요? 모든 부수 효과를 다 분리하다 보면 코드가 오히려 복잡해질 수도 있을 것 같은데, 실용적인 기준이 궁금합니다.
Basic 버전에서 Props Drilling이 심한 것을 확인했는데, Jotai 외에 다른 해결 방법(Context API, Composition Pattern 등)과 비교했을 때 어떤 것이 가장 효율적인가요?
순수 함수와 액션을 분리해놨는데, 실무에서는 어떤 부분에 우선적으로 테스트를 작성하시나요? 모든 함수에 테스트를 작성하기보다는 중요한 비즈니스 로직 위주로 작성하는 것이 맞을까요?