[TAS-6594] ✨ Rank staked books ahead of the rest in the For You feed - #1621
Conversation
There was a problem hiding this comment.
Copilot review overview
🔵 Needs a closer look
Four moderate findings must be addressed before approval.
Review effort: Lite
Findings: None
What changed in this PR
Updates the For You storefront feed to prioritize staked books while hiding latest from visible tags.
Changes:
- Adds a latest-list constant while preserving API fallback behavior.
- Fetches staking data and promotes staked books in For You results.
- Hides
latestfrom tag navigation and exposes feed state.
| File | Summary |
|---|---|
shared/utils/bookstore.ts |
Defines the latest-list constant. |
server/api/store/products.get.ts |
Preserves the latest listing as the API fallback. |
app/pages/store/index.vue |
Applies staking promotion. Four moderate findings (1 vote each) concern analytics identity, incomplete ranking coverage, request races, and impressions recorded before staking data settles. |
app/composables/use-store-tags.ts |
Controls tag visibility and staking-based feed state. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
nwingt
left a comment
There was a problem hiding this comment.
i think it is better to hide the latest tag in Airtable
| const stakedItems = items.filter(item => item.totalStaked > 0n) | ||
| if (stakedItems.length && stakedItems.length < items.length) { | ||
| items = [...stakedItems, ...items.filter(item => item.totalStaked <= 0n)] | ||
| } |
There was a problem hiding this comment.
So items are not sorted by staking amount, just move staked item to the front right?
The personalized feed was the one listing that never saw staking at all: its branch in fetchTagItems returned before the staking fetch, so every item rendered with totalStaked 0n and the server's ranking stood alone. It now lifts staked books to the front rather than re-sorting by amount, so the personalized order survives inside each group — a plain sort by stake would have left the feed indistinguishable from the 質押 tab, filtered to the reader's candidates. The lift lives in cmsProducts, not in the fetch, so a staking response that lands after the feed still reorders what is on screen. Only the store's feed lifts; the library's keeps the server order, mirroring the staking tabs the library tab already drops. The fetch is page-one-only — fetchStakingBooks pages deeper whenever it still holds a cursor, and since For You is the signed-in landing tab, letting it advance the cursor would have sent the next CMS tag to an uncached page two for no extra staked books. It is also unawaited: the lift is reactive, so making the feed's own error modal and scroll restore wait on the indexer only cost latency. A staking failure just means no lift.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Three unresolved moderate issues affect impression accuracy, malformed data handling, and ranking completeness.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
The staking fetch is unawaited, so the impression could record the server order before the lift reordered the grid. Hold the view key until the first staking fetch settles; refreshes don't hold it, so they can't re-log the view.

No description provided.