🐞 fix: 修复收藏数据200限制#618
Conversation
Summary of ChangesHello @SUBearH, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 此拉取请求主要目的是修复用户收藏数据(特别是MV和电台)在获取时存在的200条限制问题。通过在API层引入分页参数,并重构数据获取循环逻辑,确保应用能够完整地加载用户的所有收藏数据,从而提升用户体验和数据准确性。 Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
| dataStore.setUserLikeData(key as any, allData as CoverType[]); | ||
| } | ||
|
|
||
| console.log(`✅ Fetched ${allData.length} ${key} for user ${userId}`); |
There was a problem hiding this comment.
Pull request overview
This PR fixes a limitation where user collection data (favorites/subscriptions) was capped at 200 items. The solution implements proper pagination for DJ/radio and MV collections to fetch all user data.
Key changes:
- Added pagination parameters (
limit,offset) touserMvanduserDjAPI functions - Refactored
updateUserLikeDjsandupdateUserLikeMvsto use the existingsetUserLikeDataLoophelper - Modified
setUserLikeDataLoopto handle different API response structures and implement more robust pagination logic with error handling
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/api/user.ts | Added limit and offset parameters to userMv and userDj functions to support pagination |
| src/utils/auth.ts | Refactored DJ and MV update functions to use pagination loop; enhanced setUserLikeDataLoop with better error handling and support for different API response structures |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } else if (key === "playlists") { | ||
| data = result.playlist || []; |
There was a problem hiding this comment.
The handling of the "playlists" key appears to be unnecessary. The setUserLikeDataLoop function is only called with keys "artists", "albums", "mvs", and "djs" (lines 173, 178, 183, 188). The "playlists" data is handled separately in updateUserLikePlaylist (line 155), which doesn't use this loop function. Consider removing this case to avoid confusion:
let data: any[] = [];
if (key === "djs") {
data = result.djRadios || [];
} else {
data = result.data || [];
}| } else if (key === "playlists") { | |
| data = result.playlist || []; |
| // 更新偏移量 | ||
| offset += limit; | ||
| canLoop = offset < count && formattedData.length > 0; | ||
| const limit = 50; // 限制每页50条 |
There was a problem hiding this comment.
The comment "限制每页50条" (limit to 50 items per page) could be more informative. Consider explaining why 50 was chosen instead of the previous 100. For example:
const limit = 50; // Reduced from 100 to 50 to avoid API rate limits and improve reliability| const limit = 50; // 限制每页50条 | |
| const limit = 50; // Reduced from 100 to 50 to avoid API rate limits and improve reliability |
| data = result.data || []; | ||
| } | ||
|
|
||
| if (!Array.isArray(data) || data.length === 0) { |
There was a problem hiding this comment.
The check !Array.isArray(data) may not correctly handle all API responses. If the API returns a response where the expected data field is missing or null (rather than an empty array), this condition would evaluate to true and break the loop. However, this could happen on the first request, potentially leading to silent failures where no data is fetched at all.
Consider adding validation before entering the loop or providing better error messaging:
if (!Array.isArray(data)) {
if (offset === 0) {
console.error(`Unexpected response format for ${key}:`, result);
}
break;
}
if (data.length === 0) {
break; // No more data
}| if (!Array.isArray(data) || data.length === 0) { | |
| if (!Array.isArray(data)) { | |
| if (offset === 0) { | |
| console.error(`Unexpected response format for ${key}:`, result); | |
| } | |
| break; | |
| } | |
| if (data.length === 0) { |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
🐞 fix: 修复收藏数据200限制