Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the subgraph client to better support Piece CID workflows by adding paginated/batched fetching for piece details and enabling CID-based navigation from the landing page search.
Changes:
- Add
first/skippagination parameters to thepieceDetailsGraphQL query and implement batched loading inusePiecePageData. - Update
PieceDetailspage to rely on the hook’s returned dataset list for pagination. - Extend search to recognize Piece CIDs and route users to the piece details page (including network-prefixed routes).
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
subgraph-client/src/utility/queries.ts |
Adds pagination args to pieceDetailsQuery to enable batched retrieval. |
subgraph-client/src/hooks/usePiecePageData.tsx |
Implements batched fetching and deduplication for piece details data. |
subgraph-client/src/pages/PieceDetails.tsx |
Simplifies pagination inputs by using the hook’s returned pieceDetails. |
subgraph-client/src/api/apiService.ts |
Extends search result typing and adds CID result generation. |
subgraph-client/src/pages/Landing.tsx |
Adds CID navigation behavior and updates routes to include network prefix. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| {result.type === 'provider' | ||
| ? `${result.active_sets} active sets` | ||
| : result.type === 'root' | ||
| ? `${result.total_roots} roots` | ||
| : `${formatDataSize(result.data_size)}`} |
There was a problem hiding this comment.
For cid search results, data_size is currently set to an empty string, so this UI falls through to formatDataSize(result.data_size) and renders 0.00 B, which is misleading. Consider omitting the size row for cid results or making data_size optional and only rendering it for result types that actually have a meaningful size.
| interface PiecePageOptions { | ||
| activityLimit?: number | ||
| retryOnError?: boolean | ||
| } |
There was a problem hiding this comment.
activityLimit remains in PiecePageOptions but is no longer used after removing the weekly activity query. Either remove this option or reintroduce the behavior so the hook API matches what it actually does.
| if (cid) { | ||
| searchResults.push({ | ||
| type: 'cid', | ||
| id: trimmedQuery, | ||
| data_size: '', | ||
| }) | ||
| } |
There was a problem hiding this comment.
The cid search result is constructed with data_size: '' only to satisfy the type, which then propagates to the UI as a fake 0-byte size. Consider making data_size optional (or adding a dedicated field for CID results) and only setting it for result types where it’s meaningful.
There was a problem hiding this comment.
@copilot apply changes based on this feedback
There was a problem hiding this comment.
Done in commit 8bfb816. Made data_size optional in SearchResult, removed the data_size: '' from CID results, and updated Landing.tsx to skip the info row entirely for cid type results — so no more misleading 0.00 B display.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…ID results Agent-Logs-Url: https://github.com/FilOzone/pdp-explorer/sessions/dc13e8c1-bc6d-4893-86b0-aac4599c16ba Co-authored-by: kaola526 <88829586+kaola526@users.noreply.github.com>
|
fix #93 |
|
@copilot re-review |
|
I have no insight into the code. Someone else needs to be reviewed. |
silent-cipher
left a comment
There was a problem hiding this comment.
If we move the cid check earlier to handleSearch, we can simplify Landing.tsx by removing several ternaries.
Co-authored-by: Puspendra Mahariya <95584952+silent-cipher@users.noreply.github.com>
Co-authored-by: Puspendra Mahariya <95584952+silent-cipher@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Puspendra Mahariya <95584952+silent-cipher@users.noreply.github.com>
There was a problem hiding this comment.
I don’t see this addressed yet, nor any discussion on it.
My main concern is: why aren’t we checking for cid at the start of handleSearch? If the input is a cid, we could directly navigate to /${network}/piece/<cid> instead of going through search and then checking results && results[0].type === 'cid'.
The current flow introduces an unnecessary round trip and triggers an avoidable subgraph API call.
Refs - #95 (comment) , #95 (comment)
|
@kaola526 : please re-request review when it's ready to be reviewed again? |
The modifications have been made as requested. Please help review it again. Thank you. |
Co-authored-by: Puspendra Mahariya <95584952+silent-cipher@users.noreply.github.com>
Co-authored-by: Puspendra Mahariya <95584952+silent-cipher@users.noreply.github.com>
data_sizeoptional in theSearchResultinterface inapiService.tsdata_size: ''from CID search result (no longer needed)Landing.tsxto skip the additional info row forcidtype results, preventing misleading0.00 Bdisplay