Skip to content

⚡ Bolt: Optimize project detail fetching #200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
aicoder2009 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

⚡ Bolt: Optimize project detail fetching #200

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .jules/bolt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,3 +5,7 @@
## 2024-05-18 - Concurrent Fetching with Owner IDs in Share Links
**Learning:** In the share system, endpoints processing a share code typically suffer from waterfall latency by first loading target entity details (like a project) and then querying its associated elements (like project lists) using the entity's owner ID (`userId`). However, the `shareLink` object already contains the `userId` field (representing the owner's ID).
**Action:** Always leverage the existing owner's ID within `shareLink` to bypass sequential dependencies and fetch parent entities (like projects) concurrently with their child elements (like user lists) using `Promise.all`.

## 2024-05-19 - Deriving Subsets In-Memory
**Learning:** When fetching a global collection (e.g., all lists) and a subset of that collection (e.g., project lists) simultaneously on the frontend, making separate API requests leads to duplicate backend database queries and redundant network transfers.
**Action:** Always derive subsets of data in-memory on the frontend using array filtering whenever the parent collection is already being retrieved. This avoids redundant API calls and database hits, lowering both latency and resource usage.
13 changes: 5 additions & 8 deletions src/app/projects/[id]/page.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,15 +60,15 @@ export default function ProjectDetailPage({ params }: { params: Promise<{ id: st
// OPTIMIZATION: Execute independent network requests and JSON parsing concurrently
// using Promise.all. This prevents a 3-step waterfall, reducing Time to First Byte
// (TTFB) and overall load time significantly on this detail page.
const [projectRes, listsRes, allListsRes] = await Promise.all([
// OPTIMIZATION: Further reduced network requests by deriving project lists in-memory
// from the global allLists array instead of making a redundant query.
const [projectRes, allListsRes] = await Promise.all([
fetch(`/api/projects/${projectId}`),
fetch(`/api/projects/${projectId}/lists`),
fetch("/api/lists"),
]);

const [projectResult, listsResult, allListsResult] = await Promise.all([
const [projectResult, allListsResult] = await Promise.all([
projectRes.json(),
listsRes.json(),
allListsRes.json(),
]);

Expand All @@ -81,12 +81,9 @@ export default function ProjectDetailPage({ params }: { params: Promise<{ id: st
setEditName(projectResult.data.name);
setEditDescription(projectResult.data.description || "");

if (listsResult.success) {
setLists(listsResult.data);
}

if (allListsResult.success) {
setAllLists(allListsResult.data);
setLists(allListsResult.data.filter((list: List) => list.projectId === projectId));
}
Comment on lines 84 to 87

@coderabbitai coderabbitai Bot Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Inspect getUserLists ordering vs getProjectLists
rg -nP --type=ts -C4 'export\s+async\s+function\s+getUserLists' src/lib/db/

Repository: aicoder2009/opencitation

Length of output: 1299

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '--- page.tsx outline ---'
ast-grep outline src/app/projects/[id]/page.tsx --view expanded || true

echo '--- local-store.ts outline ---'
ast-grep outline src/lib/db/local-store.ts --view expanded || true

echo '--- dynamodb.ts outline ---'
ast-grep outline src/lib/db/dynamodb.ts --view expanded || true

echo '--- page.tsx slice ---'
sed -n '1,140p' src/app/projects/[id]/page.tsx

echo '--- local-store.ts slice ---'
sed -n '100,150p' src/lib/db/local-store.ts

echo '--- dynamodb.ts slice ---'
sed -n '170,240p' src/lib/db/dynamodb.ts

Repository: aicoder2009/opencitation

Length of output: 16178

Surface the /api/lists failure state here. When allListsResult.success is false, the page falls through to the empty-state UI, so a failed fetch reads as “no lists yet” instead of an error. Set error in the else branch so fetch failures don’t get masked.

🤖 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/app/projects/`[id]/page.tsx around lines 84 - 87, The project page fetch
logic in the branch that handles allListsResult should surface failures instead
of falling through to the empty state. In the same effect or data-loading flow
where setAllLists and setLists are called, add an else branch for
allListsResult.success === false that sets the error state so the /api/lists
failure is shown, rather than treating it like no lists exist.

} catch (err) {
console.error("Error fetching project:", err);
Expand Down
Loading