Update: await until saved.
#2323
Conversation
ConsoleProject ID: Sites (2)
Note Cursor pagination performs better than offset pagination when loading further pages. |
WalkthroughThe change modifies src/lib/components/limit.svelte to await an asynchronous preferences.setLimit(limit) call within the existing async limitChange function. Subsequent logic—updating the URL’s limit parameter, recalculating the page parameter based on previousLimit and the new limit if present, and navigating via goto—now executes after the limit update completes. No exported or public entity signatures were altered. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/lib/components/limit.svelte (3)
20-33: Don’t block navigation on failed preference saveIf persisting preferences rejects, the user could be stuck on the old page. Wrap the await in try/catch and proceed with navigation.
- await preferences.setLimit(limit); + try { + await preferences.setLimit(limit); + } catch (err) { + console.error('Failed to persist limit preference:', err); + // Non-blocking: continue with URL-based state + }
22-30: Page recalculation likely off-by-one; guard when previousLimit is absentIf pages are 1-indexed, the current formula can yield page=0 (e.g., page=1). Also, when
limitis missing in the URL,Number(null)becomes 0, skewing the calculation. Use a fallback and clamp to 1.- const previousLimit = Number(url.searchParams.get('limit')); + const previousLimitParam = url.searchParams.get('limit'); + const previousLimit = previousLimitParam ? Number(previousLimitParam) : limit; - const newPage = Math.floor(((page - 1) * previousLimit) / limit); + const itemStartIndex = Math.max(0, (Math.max(1, page) - 1) * previousLimit); + const newPage = Math.max(1, Math.floor(itemStartIndex / limit) + 1);Please confirm whether your app treats
pageas 1-indexed; if it is 0-indexed, we can adjust accordingly.
32-32: Prefer path+search for client-side navigationPassing only
pathname + searchavoids accidental absolute-URL navigations and respects any base path.- await goto(url.toString()); + await goto(`${url.pathname}${url.search}`);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
src/lib/components/limit.svelte(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: e2e
- GitHub Check: build
🔇 Additional comments (1)
src/lib/components/limit.svelte (1)
24-24: Good fix: awaiting preference save removes race with navigationAwaiting
preferences.setLimit(limit)ensures URL updates and pagination math run after the preference is persisted. This should resolve the timing issue described in the PR.
2 participants
What does this PR do?
Can cause issue with limit if the save took sometime.
Test Plan
N/A.
Related PRs and Issues
N/A.
Have you read the Contributing Guidelines on issues?
Yes.
Summary by CodeRabbit