You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR implements server-side pagination for the Repo Explorer. It cleanly separates the pagination functionality from the unrelated milestone/goal-category changes that caused conflicts in previous PR attempts, ensuring the UI remains fast for users with large numbers of repositories.
🐛 Bug fix (non-breaking change that fixes an issue)
✨ New feature (non-breaking change that adds functionality)
💥 Breaking change (fix or feature that changes existing behavior)
📝 Documentation update
♻️ Refactor / code cleanup (no functional change)
⚡ Performance improvement
🔒 Security fix
🧪 Tests only
What Changed
src/lib/github.ts: Introduced a new fetchUserReposPaginated function and PaginatedReposResult interface to selectively fetch a specific page of repositories and extract the hasNextPage boolean from GitHub's Link header. This avoids altering the original fetchUserRepos return signature, preserving compatibility across other endpoints.
src/app/api/metrics/repo-explorer/route.ts: Updated the endpoint to extract page and per_page query parameters. Replaced the heavy, multi-page data fetch with fetchUserReposPaginated, injecting the parameters into the cache key to accurately serve paginated chunks. The endpoint now returns { repos, hasNextPage }.
test/github.test.ts: Added validation for the new PaginatedReposResult interface.
How to Test
Navigate to the Repo Explorer section of the dashboard.
Verify that only the initial subset of repositories loads on the first request (improving TTFB).
Attempt to fetch subsequent pages (e.g. by appending ?page=2 to the API request or utilizing the UI's pagination control).
Check that hasNextPage accurately reflects the presence of remaining repositories.
Expected result: The Repo Explorer should load instantly rather than waiting for up to 10 sequential API calls, and cleanly transition between pages without duplicate renders or missing commits.
Checklist
Linked the related issue above
Self-reviewed my own diff
No unnecessary console.log, debug code, or commented-out blocks
npm run lint passes locally
No TypeScript errors (npm run type-check)
Added or updated tests where applicable
Updated documentation / comments if behavior changed
Accessibility (UI changes only)
Keyboard navigation works correctly
Color contrast meets WCAG AA standard
ARIA labels / roles added where needed
Tested on mobile / responsive layout
Additional Context
This is a focused, rebased follow-up to the previously cluttered PRs (#2903 and #3135) to implement the required API modifications securely and smoothly, ensuring a completely green build without conflicts.
gssoc:invalid / gssoc:spam / gssoc:ai-slop — does not score
Type labels (type:*) are auto-detected from files and title. Review and adjust if needed.
Points formula: (difficulty × quality_multiplier) + type_bonus
Closer, thanks for splitting it out — but this is backend-only and would regress the explorer. The consumer src/components/repo-analytics/RepoAnalyticsExplorer.tsx fetches /api/metrics/repo-explorer with no page param and ignores hasNextPage, so switching the route to per-page (default 20) means the UI now shows only the first 20 repos with no way to load more — worse than the current "fetch all up to 1000" behavior. Either (a) keep fetching all pages server-side (the #2843 fix), or (b) add the client-side pagination too (pass page, render a "load more"/pager using hasNextPage) in the same PR. Right now it's a UX regression.
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
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.
Summary
This PR implements server-side pagination for the Repo Explorer. It cleanly separates the pagination functionality from the unrelated milestone/goal-category changes that caused conflicts in previous PR attempts, ensuring the UI remains fast for users with large numbers of repositories.
Closes #3136
Type of Change
What Changed
src/lib/github.ts: Introduced a newfetchUserReposPaginatedfunction andPaginatedReposResultinterface to selectively fetch a specific page of repositories and extract thehasNextPageboolean from GitHub'sLinkheader. This avoids altering the originalfetchUserReposreturn signature, preserving compatibility across other endpoints.src/app/api/metrics/repo-explorer/route.ts: Updated the endpoint to extractpageandper_pagequery parameters. Replaced the heavy, multi-page data fetch withfetchUserReposPaginated, injecting the parameters into the cache key to accurately serve paginated chunks. The endpoint now returns{ repos, hasNextPage }.test/github.test.ts: Added validation for the newPaginatedReposResultinterface.How to Test
?page=2to the API request or utilizing the UI's pagination control).hasNextPageaccurately reflects the presence of remaining repositories.Expected result: The Repo Explorer should load instantly rather than waiting for up to 10 sequential API calls, and cleanly transition between pages without duplicate renders or missing commits.
Checklist
console.log, debug code, or commented-out blocksnpm run lintpasses locallynpm run type-check)Accessibility (UI changes only)
Additional Context
This is a focused, rebased follow-up to the previously cluttered PRs (#2903 and #3135) to implement the required API modifications securely and smoothly, ensuring a completely green build without conflicts.