[PR #103] [MERGED] fix: category counts showing (0) on community collection detail page #103

New issue

Closed

opened 2026-08-16 07:30:51 +02:00 by zaph0d · 0 comments

zaph0d commented

2026-08-16 07:30:51 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/niels-emmer/myace/pull/103
Author: @niels-emmer
Created: 8/15/2026
Status: ✅ Merged
Merged: 8/15/2026
Merged by: @niels-emmer

Base: main ← Head: fix/community-category-counts

📝 Commits (1)

7544b84 fix: category counts showing (0) on community collection detail page

📊 Changes

2 files changed (+147 additions, -9 deletions)

View changed files

➕ frontend/src/pages/CommunityCollectionDetail.test.tsx (+129 -0)
📝 frontend/src/pages/CommunityCollectionDetail.tsx (+18 -9)

📄 Description

The bug

Collections → open a community collection → click any category (Skills/Agents/Rules/…) → every other category counter drops to (0). Only "All" restores them.

Root cause

CommunityCollectionDetail.tsx fetched artifacts pre-filtered by type from the server (queryKey: ['community-artifacts', id, typeFilter], passing type:), then derived the per-category counts from that same filtered array — so every non-selected category counted zero artifacts.

This is the identical bug #51 fixed on the owned-collection page. That fix only touched CollectionDetail.tsx; the community page was never updated.

#99 and #102 misdiagnosed this as a stale cached SPA shell because only CollectionDetail.tsx was inspected. Confirmed against the live VPS bundle, which still contained the buggy per-type refetch:

queryKey:[`community-artifacts`,e,r],queryFn:()=>H.getArtifacts(e,{type:r===`all`?void 0:r,...})

The fix

Fetch the full list once, unfiltered; filter client-side via useMemo — matching CollectionDetail.tsx. Both pages now share the same approach, and the query comment explains why so it doesn't regress a third time.

Test plan

New CommunityCollectionDetail.test.tsx — verified it fails against the old query and passes against the fix (not just passing-by-default)
Full frontend suite: 22/22 pass
npm run lint clean (2 pre-existing unrelated warnings)
Production bundle inspected post-build: unfiltered fetch + client-side filter confirmed

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/niels-emmer/myace/pull/103 **Author:** [@niels-emmer](https://github.com/niels-emmer) **Created:** 8/15/2026 **Status:** ✅ Merged **Merged:** 8/15/2026 **Merged by:** [@niels-emmer](https://github.com/niels-emmer) **Base:** `main` ← **Head:** `fix/community-category-counts` --- ### 📝 Commits (1) - [`7544b84`](https://github.com/niels-emmer/myace/commit/7544b84ab3c1497aee1a7d0cf013467d46f96831) fix: category counts showing (0) on community collection detail page ### 📊 Changes **2 files changed** (+147 additions, -9 deletions) <details> <summary>View changed files</summary> ➕ `frontend/src/pages/CommunityCollectionDetail.test.tsx` (+129 -0) 📝 `frontend/src/pages/CommunityCollectionDetail.tsx` (+18 -9) </details> ### 📄 Description ## The bug Collections → open a **community** collection → click any category (Skills/Agents/Rules/…) → every other category counter drops to (0). Only "All" restores them. ## Root cause `CommunityCollectionDetail.tsx` fetched artifacts **pre-filtered by type** from the server (`queryKey: ['community-artifacts', id, typeFilter]`, passing `type:`), then derived the per-category counts from that same filtered array — so every non-selected category counted zero artifacts. This is the identical bug #51 fixed on the owned-collection page. That fix only touched `CollectionDetail.tsx`; the community page was never updated. **#99 and #102 misdiagnosed this as a stale cached SPA shell** because only `CollectionDetail.tsx` was inspected. Confirmed against the live VPS bundle, which still contained the buggy per-type refetch: ``` queryKey:[`community-artifacts`,e,r],queryFn:()=>H.getArtifacts(e,{type:r===`all`?void 0:r,...}) ``` ## The fix Fetch the full list once, unfiltered; filter client-side via `useMemo` — matching `CollectionDetail.tsx`. Both pages now share the same approach, and the query comment explains why so it doesn't regress a third time. ## Test plan - [x] New `CommunityCollectionDetail.test.tsx` — **verified it fails against the old query and passes against the fix** (not just passing-by-default) - [x] Full frontend suite: 22/22 pass - [x] `npm run lint` clean (2 pre-existing unrelated warnings) - [x] Production bundle inspected post-build: unfiltered fetch + client-side filter confirmed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

zaph0d

2026-08-16 07:30:51 +02:00