React Query 를 선택적으로 쓰는 방법

현재 상황 분석

1. RootLayout과 ClientLayout 구조:

   • RootLayout 안에 ClientLayout이 있으며, ClientLayout에서 react-query의 QueryClientProvider와 jotai의 Provider를 설정하고 있습니다.
   • 모든 페이지에서 ClientLayout을 통해 이러한 Provider들이 적용되기 때문에, 전체 애플리케이션이 이들의 영향을 받게 됩니다.

2. 팀원들의 우려 사항:

   • react-query와 jotai의 Provider를 최상위 레벨에 배치하면, 해당 라이브러리를 사용하지 않는 다른 페이지에도 불필요한 영향이나 성능 저하가 발생할 수 있다는 우려입니다.

문제의 원인과 팀원들의 우려 분석

• 공통 컴포넌트 의존성:

  • Header 컴포넌트는 모든 페이지에 포함되며, 이 Header는 useAuth 훅을 사용하고 있습니다.
  • useAuth 훅은 react-query와 jotai에 의존하고 있기 때문에, Header를 사용하는 모든 페이지에서 이들 Provider가 필요합니다.

• 팀원들의 우려 점검:

  • 성능 문제: react-query와 jotai는 경량의 라이브러리로, Provider를 추가한다고 해서 큰 성능 저하가 발생하지 않습니다.
  • 불필요한 의존성: 하지만, 해당 라이브러리를 사용하지 않는 페이지에서 굳이 Provider를 포함해야 하느냐는 질문은 타당합니다.

이점과 권장사항

• 이점 설명:

  • 유지 보수성 향상: Layout을 분리함으로써 각 페이지의 의존성을 명확히 관리할 수 있습니다.
  • 성능 최적화: 필요한 페이지에만 Provider를 적용하여 불필요한 리소스 소비를 방지합니다.

• 권장사항:

  • Provider의 전역 적용은 불가피합니다: Header가 모든 페이지에 포함되어 있고, useAuth 훅이 Provider를 필요로 하기 때문에, Provider를 특정 페이지에서만 적용하는 것은 불가능합니다.

  • ClientLayout을 활용하여 필요한 부분만 클라이언트 컴포넌트로 처리: 이렇게 하면 성능 저하 없이 문제를 해결할 수 있습니다.

최종 제안

• Layout 분리 적용:

  • 인증이 필요한 페이지와 그렇지 않은 페이지를 구분하여 Layout을 분리합니다.
  • react-query와 jotai의 Provider는 인증이 필요한 페이지의 Layout에서만 사용합니다.

• 코드 구조 정리:

  • 폴더 구조와 컴포넌트 구조를 재정비하여 각 기능의 의존성을 명확히 합니다.

• 팀 내 합의 도출:

  • 제안된 방안을 팀원들과 공유하고, 피드백을 받아 최종 결정을 내립니다.