[11팀 한수지] Chapter 1-3 React, Beyond the Basics

[nincoding]

과제 체크포인트

배포 링크

https://nincoding.github.io/front_5th_chapter1-3/

기본과제

• shallowEquals 구현 완료
• deepEquals 구현 완료
• memo 구현 완료
• deepMemo 구현 완료
• useRef 구현 완료
• useMemo 구현 완료
• useDeepMemo 구현 완료
• useCallback 구현 완료

심화 과제

• 기본과제에서 작성한 hook을 이용하여 렌더링 최적화를 진행하였다.
• Context 코드를 개선하여 렌더링을 최소화하였다.

과제 셀프회고

기술적 성장

코드 품질

학습 효과 분석

과제 피드백

리뷰 받고 싶은 내용

Q1. Context Provider의 중첩으로 인해 발생하는 구조를 개선하는 방법

// App.tsx
  <ThemeProvider>
    <NotificationProvider>
      <UserProvider>
        <UserItemProvider>{children}</UserItemProvider>
      </UserProvider>
    </NotificationProvider>
  </ThemeProvider>

AppContext를 기능별로 분리하였더니 위 코드와 같이 여러개의 Context가 중첩되면서 Provider Nesting이 깊어집니다.

만약 향후 더 많은 기능이 추가된다면, Context별로 Provider가 계속해서 추가되어 깊이가 늘어나고 복잡도가 높아져서 유지보수하기에 부담이 생길 것 같습니다.

이럴 경우 외부 상태관리 라이브러리를 사용하는 것이 최선일까요?
만약 외부 라이브러리를 사용하지 않고도 Context API를 최적화할 수 있는 방법이 있다면 궁금합니다!

Q2. UI와 비지니스 로직의 분리를 효과적으로 하는 방법

리액트로 개인 프로젝트를 개발하다 보면, 컴포넌트 내부에 API 호출, 폼 유효성 검사, 상태 전이 등 다양한 로직이 뒤섞이면서 컴포넌트가 점점 비대해지고, 재사용성과 유지보수성이 떨어지는 문제가 자주 발생합니다.

이런 문제를 해결하기 위해 커스텀 훅을 활용해 로직을 분리하거나, API 호출 같은 도메인 중심의 로직은 서비스 레이어로 추상화하는 등 UI와 비즈니스 로직을 나누려 하고 있습니다.

다만, 커스텀 훅으로 감싸는 게 적절한 로직과 서비스 레이어로 분리해야 할 로직 사이의 경계를 명확히 구분하는 것이 쉽지 않습니다. 예를 들어, useForm 훅 안에서 API 호출을 직접 처리해도 괜찮은지, 아니면 그 부분은 별도 서비스 함수로 분리하는 게 맞는지 헷갈릴 때가 많습니다.

커스텀 훅이 주로 UI 컨텍스트와 밀접한 상태와 동작을 추상화하는 데 사용된다면, 서비스 레이어는 어떤 역할과 책임을 가져야 할까요? 구체적인 기준이나 예시가 있다면 알려주시면 감사하겠습니다.

[SeongYoonMin]

수지님 깔끔한코드 잘보고갑니다..! Q1질문을 보고 저도 이게 너무 Provider지옥에 빠지는거 아닌가..?라는 생각을 해보게되었고, 저는 좀 관련된 Provider끼리 묶어서 하나의 새로운 Provider를 생성해보면 어떨까싶어요..! 물론 외부 라이브러리로 깔끔하게 처리하는것도 좋지만 왠지 그걸 바라고 질문하신건 아닌거같아서... 짧은 식견이지만 의견 한줄 남기고갑니다..! 코드 너무 잘보았어요!!

[dosilv]

수지님~~ 항상 말씀하실 때 너무 똑부러지신다고 생각했는데 코드도 PR도 수지님을 닮았네요..😊
context API는 준일코치님도 아고라에 남기셨지만, 말씀하신 Provider nesting 문제도 그렇고 렌더링 측면에서도 비효율적인 면이 있어서 실제 프로덕트에서 모든 전역 상태를 context로 관리하는 건 적절하지 않은 듯 싶어요! 주로 컴파운드 컴포넌트 구성에 사용하거나, theme처럼 변경이 잦지 않으면서도 전역적으로 필요한 상태를 사용할 때 prop drilling을 해소할 수 있어서 유용하구요.
api 호출을 어디 둘지에 대해선 늘 의견이 갈리는데, 저는 프로젝트에서 이미 서비스 레이어를 사용한다면 일관성을 위해 거기 두고, 따로 없고 규모가 작다면 hook에서 하되 상태관리와는 분리해서 api 호출을 위한 hook을 따로 작성하는 편이에요. 그렇게 하면 나름대로 단일책임 원칙을 지키면서도 재사용성이 향상되더라구요!
그리고 사소하지만 formData를 묶어서 useState로 선언하시는 부분에선 formData에 대한 타입을 정의해두고 쓰면 as string[] 같은 타입 단언도 제거할 수 있고, setFormData 사용시에도 타입 강제가 가능해서 조금 더 안전할 것 같아요!
넘 늦었지만 코드 잘 구경하구 코멘트 남겨봅니당ㅎ.ㅎ 이번주도 파이팅이에요!💪🏻💪🏻