[Step2.1] cactus: Context API 적용하기 - #4
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthrough전역 상태를 Context Provider와 커스텀 훅으로 분리하고, 앱과 레스토랑/모달 컴포넌트가 props 대신 컨텍스트를 직접 사용하도록 바꿨다. 샘플 데이터와 상태관리 학습 README들도 함께 갱신됐다. ChangesContext API 상태관리 전환
Sequence Diagram(s)sequenceDiagram
participant RestaurantProvider
participant ModalProvider
participant App
participant Header
participant AddRestaurantModal
participant ModalContext
participant RestaurantContext
RestaurantProvider->>ModalProvider: render children
ModalProvider->>App: render App
App->>Header: render add button
Header->>ModalContext: handleAddModalOpen()
App->>AddRestaurantModal: render when isAddModalOpen
AddRestaurantModal->>ModalContext: handleFormSubmit(newRestaurant)
ModalContext->>RestaurantContext: registerRestaurant(newRestaurant)
ModalContext->>AddRestaurantModal: handleAddModalClose()
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
| export const ModalContext = createContext(null); | ||
|
|
||
| export function ModalProvider({ children }) { | ||
| const { registerRestaurant } = useRestaurantContext(); |
There was a problem hiding this comment.
[논의]
현재 ModalProvider 내부에서 useRestaurantContext()를 호출하고 있는데 이로 인해서 2가지 문제가 생긴다고 생각합니다.
- Provider 중첩 순서가 암묵적인 제약이 된다.
- ModalProvider를 단독으로 테스트할 수 없다.
이를 개선하기 위한 방법으로는 registerRestaurant를 ModalProvider의 prop으로 받도록 변경하면 의존성이 명시적으로 드러나고 두 Context가 독립적으로 존재할 수 있다고 생각합니다.
예령님은 어떻게 생각하시는지 궁금합니다. 또한 코드를 이렇게 작성하게 된 이유가 있다면 공유해주세요!
There was a problem hiding this comment.
Provider 중첩 순서 문제는 저도 인지하고 있었는데, 순환 참조가 생기지 않도록 의존 방향만 단방향으로 고정하면 된다고 생각하고 넘어갔습니다. prop으로 받아서 의존성을 명시적으로 드러내는 방법은 생각 못 했는데 좋은 방법인 것 같아요!
다만 현재 ModalContext 자체를 제거하는 쪽으로 리팩토링을 계획중입니다. UI 상태는 App의 직접 자식들에게만 필요한 상태라 Context에 올릴 이유가 없었는데, props drilling 제거가 목표가 되면서 과하게 올린 게 있었다는 판단이 들었습니다! 그래서 UI 상태는 App 로컬로 되돌리고 props로 내려줄 예정입니다. 이렇게 되면 Context 간 의존 자체가 사라져서 지적해주신 문제가 근본적으로 해결될 것 같습니다.
제가 구현한 방향 안에서 문제 해결 방법을 고민해주셔서 감사합니다!
There was a problem hiding this comment.
[배움]
저는 Context 사용부에서 컴포넌트마다 직접 useContext를 사용했는데 별도의 커스텀 훅을 사용하면 이점이 명확하다는 생각이 드네요!
- null 체크를 컴포넌트마다 반복하지 않아도 된다.
- Context를 내부 구현으로 숨겨서, 컴포넌트가 상태 관리의 구현 방식에 의존하지 않도록 할 수 있다.
2 participants
개인 목표 달성 여부
createContext,Provider,useContext의 역할과 데이터 흐름을 이해하고, 세 요소가 어떻게 연결되는지 스스로 설명할 수 있는 수준으로 익힌다.리뷰어에게
RestaurantContext와ModalContext로 나눈 분리 기준이 적절한지 피드백 부탁드립니다.ModalContext가RestaurantContext에 단방향으로 의존하는 구조가 적절한지 함께 논의하면 좋을 것 같습니다.Context API를 사용한 이유와 trade-off
왜 Context API를 선택했는가
기존 코드에서 props drilling이 심각하게 발생하지는 않았습니다. 컴포넌트 트리가 얕아서 App의 모든 자식이 App에서 직접 props를 받고 있었고, 중간에 전달만 하는 컴포넌트가 없었습니다.
대신 다른 문제가 있었습니다.
App.jsx가 상태 3개, 핸들러 6개, 필터 계산 로직을 전부 들고 있어 역할이 지나치게 집중된 상태였습니다. 상태와 함수를 관심사 기준으로 나눠 Context로 분리하는 것이 적합하다고 판단했습니다.RestaurantContext— 레스토랑 목록, 카테고리 필터처럼 데이터 자체와 관련된 상태ModalContext— 모달 열림/닫힘, 선택된 레스토랑처럼 UI 상태trade-off
Context API와 컴포넌트 관계 도식
Summary by CodeRabbit
New Features
Documentation
Bug Fixes