From abe80cc75551f8965a35721a63d865d991e33723 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Tue, 30 Jun 2026 08:26:28 +0000
Subject: [PATCH] perf(ui): optimize project lists fetching in-memory

Removed the redundant `fetch('/api/projects/${projectId}/lists')` API call in the project details page. The project-specific lists are now derived in-memory by filtering the results of the `fetch('/api/lists')` call, saving a database query and reducing network payload.

Co-authored-by: aicoder2009 <127642633+aicoder2009@users.noreply.github.com>
---
 .jules/bolt.md                 |  4 ++++
 src/app/projects/[id]/page.tsx | 13 +++++--------
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/.jules/bolt.md b/.jules/bolt.md
index 43fafef..b5aa8cf 100644
--- a/.jules/bolt.md
+++ b/.jules/bolt.md
@@ -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.
diff --git a/src/app/projects/[id]/page.tsx b/src/app/projects/[id]/page.tsx
index 8e121a4..a486b02 100644
--- a/src/app/projects/[id]/page.tsx
+++ b/src/app/projects/[id]/page.tsx
@@ -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(),
       ]);
 
@@ -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));
       }
     } catch (err) {
       console.error("Error fetching project:", err);