fix(search-explore): eliminate per-card remixes-count N+1 in featured contests#14412
Open
dylanjeffers wants to merge 1 commit into
Open
fix(search-explore): eliminate per-card remixes-count N+1 in featured contests#14412dylanjeffers wants to merge 1 commit into
dylanjeffers wants to merge 1 commit into
Conversation
… contests
Rendering the new search-explore page fired ~20 GET
/v1/tracks/:id/remixes?limit=0&only_contest_entries=true requests —
one per ContestCard in the Featured Remix Contests carousel.
Root cause: `useExploreContent` (the hook backing the carousel) reads
a static `explore-content.json` listing featured contest track IDs
with no entry-count data, so each ContestCard's
`useRemixesCount({trackId, isContestEntry: true})` independently
fires a count-only request. The cache-priming side-effect that other
contest surfaces rely on
(`packages/common/src/api/tan-query/events/useAllRemixContests.ts:93-103`,
also mirrored in `useUserRemixContests`) wasn't reachable from this
surface.
Fix: piggy-back on `useAllRemixContests`'s built-in prime by calling
it side-effect-only in `FeaturedRemixContestsSection`, gated on the
same `inView` as the main fetch. One batched request seeds the
remixes-count cache for the top-N active contests; ContestCards then
hit cache instead of issuing their own count fetches. Featured
contests in the prime batch (the common case — featured is a
curated subset of active) drop from N requests to 0.
No backend or shared-hook changes; isolated to the carousel section.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Contributor
🌐 Web preview readyPreview URL: https://audius-web-preview-pr-14412.audius.workers.dev Unique preview for this PR (deployed from this branch). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Loading the new search-explore page fires ~20 `GET /v1/tracks/:id/remixes?limit=0&offset=0&only_contest_entries=true&only_cosigns=false` requests — one per ContestCard in the Featured Remix Contests carousel.
Root cause
`FeaturedRemixContestsSection` calls `useExploreContent`, which reads a static `explore-content.json` listing featured contest track IDs with no entry-count data. Each `` then independently issues a count-only request via `useRemixesCount({ trackId, isContestEntry: true })` (`packages/web/src/components/contest-card/ContestCard.tsx:255`). N cards = N requests.
The cache-priming side-effect that other contest surfaces rely on already exists in `packages/common/src/api/tan-query/events/useAllRemixContests.ts:93-103` (and mirrored in `useUserRemixContests.ts:100`) — it walks `related.entryCounts` and calls `queryClient.setQueryData(getRemixesCountQueryKey(...), count)` for each contest, turning ContestCard's count fetch into a cache hit. But `useExploreContent` doesn't return entry counts, so this surface never benefited.
Fix
Piggy-back on `useAllRemixContests`'s built-in prime by calling it side-effect-only in the section, gated on the same `inView` as `useExploreContent`. One batched request seeds the remixes-count cache for the top-30 active contests; ContestCards in the featured carousel then hit cache instead of firing their own count fetches.
```tsx
useAllRemixContests({ pageSize: PRIME_BATCH_SIZE }, { enabled: inView })
```
The return value is intentionally unused — we only care about the priming inside the hook's queryFn.
Why not a backend fix
The cleanest solution would be to extend `explore-content.json` (or a new endpoint) to include entry counts per featured contest. That requires a static-content rebuild + a hook signature change, which is out of scope for this fix. The client-side prime above resolves the immediate N+1 with one extra request total, deferring the backend cleanup.
Test plan
🤖 Generated with Claude Code