-
Notifications
You must be signed in to change notification settings - Fork 47
[1팀 천진아] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계 #5
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
totter15
wants to merge
26
commits into
hanghae-plus:main
Choose a base branch
from
totter15: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
- 컴포넌트 분리: SelectList, CartListItem, ProductListItem 추가 - 비즈니스 로직 분리: models/cart.ts에 장바구니 계산 로직을 순수 함수로 분리 - 유틸리티 추가: validators.ts 추가
- 컴포넌트를 domain, ui, icons 폴더로 재구성 - SVG 아이콘을 별도 컴포넌트로 추출 - 배럴 익스포트 패턴 적용
- useDebounce, useLocalStorage, useNotification 훅 추가 - formatter 유틸리티 함수 추가 - 장바구니 관련 로직 개선
- 상품 관련 컴포넌트 분리 (ProductForm, ProductTable, ProductTableItem) - Product 모델 타입 정의 추가
- ProductSection과 CouponSection으로 관심사 분리 - 쿠폰 관련 컴포넌트 및 모델 구현 - 각 Section이 자체 상태 관리하도록 개선
- 쿠폰/제품 관리 컴포넌트를 adminPage 폴더로 이동 - 장바구니/제품 목록 컴포넌트를 cartPage 폴더로 이동 - 미사용 CouponList 컴포넌트 제거 - 관련 모델 및 페이지 파일 업데이트
- components/domain -> components/pages로 폴더명 변경 - useNotification hook을 advanced/hooks로 이동하여 구조 개선 - AdminPage, CartPage에서 useNotification 통합 - Notification 컴포넌트 UI 개선
- 미사용 아이콘 컴포넌트 삭제 (AdminIcon, CheckIcon, ChevronDownIcon, ChevronUpIcon, MinusIcon, PlusIcon) - TrashIcon 및 index.tsx 정리 - CouponListItem 업데이트
- basic/App.tsx: useNotification import 경로 수정 - basic/components/ui/Header.tsx: optional props 타입 안전성 개선 - basic/components/ui/Notification.tsx: types.ts의 Notification 타입 사용 - advanced/App.tsx: 미사용 import 제거 (useDebounce)
- ProductListItem에서 useCart 훅 직접 사용하여 props drilling 제거 - useNotification에 deleteNotification 함수 추가로 API 캡슐화 개선 - 불필요한 console.log 제거
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.
배포링크
https://totter15.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는 잘 제거했나요?
전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?
과제 셀프회고
진행순서
1) 큰 단위의 구조 분리
눈에 보이는 UI를 기준으로 먼저 분리가능한 단위를 크게 쪼개고 시작을 했습니다.
2) 주요상태(데이터) 정리
=> App에서 한뭉치로 보이는게 아니어서 코드 파악하기 더 수월해졌던것 같습니다.
메인으로 사용되는 주요 data는
products,cart,coupons,notifications인것 같습니다.각 데이터와 이런 데이터를 변경시키는 함수를 정리하면 아래처럼 정리할 수 있었습니다.
3) 각 상태를 hook으로 분리
위에서 정리한 값들을 기반으로 데이터를 조작하는 함수(액션)들을 hook으로 만들어 주었습니다.
4) 각 hook에서 계산 분리
현재 만들어진 hook들은 상태를 바꾸는 action 이기에 테스트하기 쉽게 내부의 로직을 계산으로 만들어 models로 분리 시켜주었습니다.
5) 각 컴포넌트 UI를 분리
컴포넌트를 하나의 역할/단위로 분리되는 것들을 기준으로 나눠주었습니다. Form, List, ListItem, Table등
엔티티를 사용하지 않는 공통 컴포넌트는 ui폴더에 분리해 주었습니다. 폴더구조에 대해서는 다음주차에 좀더 딥하게 다룰것같아 이번 과제에서는 라이트하게 분리를 하려 했습니다.
6) 상태관리를 통해 props drilling 제거
리액트로만 작업하고 싶어 상태관리 툴로는 useContext를 사용했습니다. 여러 계층에서 사용되는 cart, product, coupon, notification은 다른 계층에서 사용가능하도록 useContext를 이용해 분리시켜주었습니다.
과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?
기존에는 domain보다는 사실 UI를 기준으로 컴포넌트 분리를 많이 했던것 같습니다. 이전 발제에서 말씀하신것 처럼 다른 도메인이지만 비슷한 UI사용시 동일 컴포넌트를 사용했는데, 1회차, 2회차 과제를 통해서 UI기준으로 생각하는 방식 -> 계층, 도메인 기준으로 hook과 컴포넌트를 바라보게 된것 같습니다.
이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!
회사에서 사용하는 코드들을 리팩토링해보면 좋을것 같습니다! 지금 회사코드가 UI와 로직들이 뒤섞여 있어서...파트별로 하나씩 리팩토링을 하면 좋을것 같습니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
CartPage의 handleApplyCoupon, handleAddToCart, handleUpdateQuantity함수가 절차적이라 느껴집니다. 이걸 개선하려면 이 함수들 또한 hook으로 분리해주는게 좋은 방법일까요? useCart => cart리스트에 대해 CRUD hook, useCartAction => useCart를 이용해 비지니스 요구사항 추가한 hook
컴포넌트를 분리할때 사실 관성대로 나눈것 같은 기분이 듭니다... cartPage의 경우 역할이 있는것들 위주로 분리를 했는데 여전히 복잡하게 느껴지기도 합니다. 페이지의 구조가 더 잘 보일수 있으려면 장바구니 결제영역, 상품이 보이는 영역을 또한 나누는게 더 좋은 방법일까요?
컴포넌트를 어느정도까지 분리를 하는게 맞을까요? 페이지단위에서 구조가 잘보일수 있도록...? 아니면 꼭 기능적으로 동작하는(form, table 같은..?) 단위로..?
notification은 entities라고 할수 있을까요? 데이터는 맞는것 같은데 이게 비지니스 데이터라 하기엔 모호한것 같은 기분이 듭니다...