feat: 기사님 상세 리뷰 페이지네이션에 prefetch 적용 - #77
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
Changes리뷰 페이지 프리페치
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant Pointer
participant Pagination
participant MoverDetailReviews
participant ReactQuery
participant getMoverReviews
Pointer->>Pagination: 다른 페이지에 포인터 진입 또는 포커스
Pagination->>MoverDetailReviews: 페이지 번호 전달
MoverDetailReviews->>ReactQuery: 리뷰 쿼리 prefetch 요청
ReactQuery->>getMoverReviews: mover와 페이지 정보로 API 호출
getMoverReviews-->>ReactQuery: 리뷰 데이터 반환
ReactQuery-->>MoverDetailReviews: 리뷰 데이터 캐시 저장
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/components/mover/detail/MoverDetailReviews.tsx (1)
57-65: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win리뷰 쿼리 옵션을 공통화해 주세요.
현재
useMoverReviews와prefetchReviewPage는 동일한 query key와 API 계약을 사용하므로 캐시 미스 문제는 없습니다. 다만 쿼리 계약이 중복되어 변경 시 불일치가 발생할 수 있습니다. 쿼리 옵션 팩토리 또는 전용 훅으로 공통화해 주세요.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/mover/detail/MoverDetailReviews.tsx` around lines 57 - 65, Extract the shared reviews query key and query function used by useMoverReviews and prefetchReviewPage into a reusable query-options factory or dedicated hook, then have both paths consume it. Anchor the change around prefetchReviewPage and useMoverReviews, preserving moverId, page, and MOVER_REVIEW_PAGE_LIMIT in the shared contract.Source: Path instructions
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/components/mover/detail/MoverDetailReviews.tsx`:
- Around line 57-65: Extract the shared reviews query key and query function
used by useMoverReviews and prefetchReviewPage into a reusable query-options
factory or dedicated hook, then have both paths consume it. Anchor the change
around prefetchReviewPage and useMoverReviews, preserving moverId, page, and
MOVER_REVIEW_PAGE_LIMIT in the shared contract.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 2b226bf0-d278-444c-92c9-d2109b9a29a6
📒 Files selected for processing (2)
src/components/common/Pagination/Pagination.tsxsrc/components/mover/detail/MoverDetailReviews.tsx
juengseulki
left a comment
juengseulki
left a comment
There was a problem hiding this comment.
전체 변경사항 확인했습니다!
👍 좋았던 점
- 기사 상세 리뷰 페이지 이동 전에 대상 데이터를 미리 요청해 체감 전환 속도를 개선했습니다.
- 기존 리뷰 조회 Query Key와 API 함수를 prefetch에도 동일하게 사용했습니다.
- Query Key에 기사 ID, 페이지 번호, 페이지 크기를 모두 포함해 기존
useMoverReviews캐시와 정확히 연결했습니다. - 프리패치 데이터가 별도 상태로 관리되지 않고 TanStack Query 캐시에서 자연스럽게 재사용되도록 구성했습니다.
- hover 프리패치는 필수 작업이 아니므로 Promise를 기다리지 않고 비동기로 실행했습니다.
onPagePrefetch를 선택적 Prop으로 추가해 기존 Pagination 사용처에 영향을 주지 않았습니다.- 페이지 번호뿐 아니라 이전·다음 버튼에도 동일한 프리패치 동작을 적용했습니다.
- 프리패치 대상 페이지를 유효 범위로 보정해 잘못된 페이지 요청을 방지했습니다.
- 현재 페이지는 프리패치 대상에서 제외해 불필요한 호출을 줄였습니다.
- 비활성화된 이전·다음 버튼에서도 결과적으로 현재 페이지와 같아져 추가 요청이 발생하지 않습니다.
- 변경 파일이 두 개로 제한되어 있고 공통 Pagination과 실제 데이터 조회 화면의 책임도 잘 나뉘어 있습니다.
- 현재 PR은 열려 있고 병합 가능한 상태이며, 한 개의 커밋으로 구성되어 있습니다.
🔍 확인 및 제안
현재 프리패치는 포인터 진입 기준으로만 실행됩니다.
따라서 키보드로 페이지 버튼에 포커스한 사용자는 클릭 전 프리패치 효과를 받지 못하지만,
클릭 시 기존 Query가 정상적으로 실행되므로 기능상 문제는 없습니다.
성능 경험까지 동일하게 제공하고 싶다면
페이지 번호와 이전·다음 버튼에 onFocus 프리패치를 함께 적용하는 것도 고려할 수 있습니다.
또한 hover가 매우 빠르게 여러 페이지를 지나가면
여러 페이지의 API 요청이 발생할 수 있습니다.
다만 Pagination에 표시되는 버튼 수가 제한적이고
TanStack Query가 동일 Query Key 요청을 중복 처리하지 않기 때문에
현재 범위에서는 과도한 네트워크 비용으로 이어질 가능성은 크지 않아 보입니다.
상세 정보와 리뷰 첫 페이지를 기사 카드 hover 시 함께 prefetch하는 개선은
현재 PR과 분리한 것이 적절해 보입니다.
그 작업은 목록 카드 수만큼 요청 가능성이 늘어날 수 있어,
staleTime, 사용자 의도 판단, 네트워크 비용을 별도로 검토하는 편이 좋습니다.
수고하셨습니다! 😊
To Reviewer 내용 기준으로 페이지 hover 시 사전 요청과
클릭 후 TanStack Query 캐시 재사용 흐름을 중점적으로 확인했습니다!
현재 구현에서는 페이지 번호나 이전·다음 버튼에 포인터가 진입하면
onPagePrefetch를 통해 대상 페이지 번호가 전달됩니다.
MoverDetailReviews에서는 해당 페이지 번호로 다음과 같은 Query를 미리 실행합니다.
- 기존 리뷰 조회와 동일한 Query Key
- 동일한 기사 ID
- 동일한 페이지 번호
- 동일한
MOVER_REVIEW_PAGE_LIMIT - 동일한
getMoverReviews()API 함수
따라서 hover 시 prefetch가 완료됐다면,
사용자가 해당 페이지를 클릭해 currentPage가 변경됐을 때
useMoverReviews가 같은 Query Key의 캐시 데이터를 재사용할 수 있는 구조입니다.
현재 페이지는 프리패치 대상에서 제외되고,
이전·다음 버튼도 경계에서 유효 페이지 범위로 보정되기 때문에
존재하지 않는 페이지에 대한 요청도 발생하지 않습니다.
프리패치 Promise를 기다리지 않으므로
사용자가 hover 직후 바로 클릭해도 이동 자체가 차단되지는 않습니다.
이 경우 prefetch가 먼저 완료됐다면 캐시를 즉시 사용하고,
아직 진행 중이라면 TanStack Query가 동일 Query Key의 진행 중 요청을 공유하는 흐름을 기대할 수 있습니다.
추가 성능 개선을 별도 작업으로 분리한 방향도 적절해 보입니다.
특히 기사님 찾기 카드 hover 시
- 기사 상세
- 리뷰 첫 페이지
를 모두 prefetch하면 사용자 체감은 좋아질 수 있지만,
카드를 빠르게 탐색할 때 요청량이 크게 늘어날 수 있습니다.
따라서 해당 개선은 다음 항목을 함께 검토한 뒤 진행하는 것이 좋겠습니다.
- hover 지연 시간
- staleTime
- 네트워크 환경
- 모바일에서는 hover가 없다는 점
- 실제 상세 진입률
- 여러 카드 연속 hover 시 요청량
|
@juengseulki
|
2 participants
📋 작업 내용
🔥 변경 사항
MoverDetailReviewsprefetchQuery로 hover한 리뷰 페이지 데이터를 미리 캐시하도록 추가했습니다.PaginationonPagePrefetchprop을 추가했습니다.✅ 체크리스트
💬 To Reviewer
Summary by CodeRabbit