feat(catalog): sortable results, sub-category filter, recently-added heading#25
Conversation
…loan mode, sort/pagination race guard, sort discoverability + a11y, sub-category breadcrumb, genrePath depth cap
|
Warning Review limit reached
Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughIntrodotto un parametro di ordinamento (sort) end-to-end dal contratto OpenAPI fino all'UI di ricerca, con enum BookSort e protezione da risultati stale. Aggiunta modalità catalogo-only nella Home tramite FeatureStore. Migliorata la navigazione a cascata dei generi nei filtri. Aggiornate traduzioni i18n in quattro lingue. ChangesOrdinamento catalogo, modalità Home e filtri genere
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant SearchScreen
participant SearchViewModel
participant CatalogRepository
participant PinakesApi
SearchScreen->>SearchViewModel: setSort(BookSort)
SearchViewModel->>SearchViewModel: incrementa searchGeneration, aggiorna stato
SearchViewModel->>CatalogRepository: search(filters, sort=apiValue)
CatalogRepository->>PinakesApi: search(sort=sort?.takeIf notBlank)
PinakesApi-->>CatalogRepository: risultati catalog/search?sort=...
CatalogRepository-->>SearchViewModel: ApiResult<SearchPage>
SearchViewModel->>SearchViewModel: verifica generazione, scarta se stale
SearchViewModel-->>SearchScreen: nuovo stato con risultati/sort attivo
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… contract - observeCache() offline fallback filtered to available copies unconditionally, so in catalogue-only mode the "Recently added" shelf still hid unavailable titles from the cached snapshot — the same label/data mismatch the refresh() path was fixed for. Branch it on catalogueMode too (unfiltered in catalogue mode). - Sync the app's API contract (_contract/openapi.json + MOBILE_API_SPEC.md) with the new catalog-search `sort` param (newest/oldest/title_asc/title_desc).
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/src/main/java/com/pinakes/app/ui/screens/home/HomeViewModel.kt (1)
94-101: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAggiornare il KDoc di
refresh()ehasFreshShelfper il comportamento condizionale.Il KDoc di
refresh()(righe 85-91) descrive ancora lo shelf come "the server-sideavailable=truequery", ma in modalità catalogo-only la query è senza filtro di disponibilità. Anche il KDoc dihasFreshShelf(righe 43-48) menziona "server-sideavailable=truepage" che non è più sempre vero.📝 KDoc aggiornato per
refresh()/** * Refresh the shelf and the offline cache concurrently. The shelf is the server-side - * `available=true` query (the catalog can hold hundreds of titles whose newest page is - * fully on loan — only the server knows what's loanable now); the unfiltered first - * page keeps feeding the Room cache for offline starts. A shelf failure only surfaces - * an error when there is nothing cached to fall back on. + * query filtered by availability in loan mode, or unfiltered in catalogue-only mode + * (the catalog can hold hundreds of titles whose newest page is fully on loan — only + * the server knows what's loanable now); the unfiltered first page keeps feeding the + * Room cache for offline starts. A shelf failure only surfaces an error when there + * is nothing cached to fall back on. */📝 KDoc aggiornato per
hasFreshShelf/** - * True once a server-side `available=true` page has been rendered this session. From + * True once a server-side shelf page has been rendered this session. From * that point the shelf is authoritative and cache emissions must not overwrite it — * the cache only holds the first unfiltered page, a subset of the real answer. */🤖 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 `@app/src/main/java/com/pinakes/app/ui/screens/home/HomeViewModel.kt` around lines 94 - 101, The KDoc for refresh() and hasFreshShelf in HomeViewModel is now inaccurate because the shelf query is conditional: catalogue mode uses an unfiltered newest-titles search, while loan mode still uses availableOnly=true. Update the documentation on refresh() and hasFreshShelf to describe this branching behavior and remove the claim that the shelf is always a server-side available=true query, keeping the wording aligned with the SearchFilters logic and shelf search in refresh().
🤖 Prompt for all review comments with 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.
Inline comments:
In `@app/src/main/java/com/pinakes/app/ui/screens/home/HomeViewModel.kt`:
- Around line 94-101: HomeViewModel is reading features.features.value only once
in refresh(), so the shelf can be built with the old catalogueMode before
FeatureStore updates. Update HomeViewModel to observe features.features and
trigger refresh() when catalogueMode changes, or delay initial home loading
until the feature refresh completes. Use the existing refresh(), observeCache(),
and hasFreshShelf flow to ensure the shelf is rebuilt with the current mode
instead of being kept stale.
---
Nitpick comments:
In `@app/src/main/java/com/pinakes/app/ui/screens/home/HomeViewModel.kt`:
- Around line 94-101: The KDoc for refresh() and hasFreshShelf in HomeViewModel
is now inaccurate because the shelf query is conditional: catalogue mode uses an
unfiltered newest-titles search, while loan mode still uses availableOnly=true.
Update the documentation on refresh() and hasFreshShelf to describe this
branching behavior and remove the claim that the shelf is always a server-side
available=true query, keeping the wording aligned with the SearchFilters logic
and shelf search in refresh().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b35a5acd-8bc4-41a1-bdea-ad4f2d5aed8b
📒 Files selected for processing (13)
_contract/MOBILE_API_SPEC.md_contract/openapi.jsonapp/src/main/java/com/pinakes/app/data/network/PinakesApi.ktapp/src/main/java/com/pinakes/app/data/repository/CatalogRepository.ktapp/src/main/java/com/pinakes/app/ui/screens/home/HomeScreen.ktapp/src/main/java/com/pinakes/app/ui/screens/home/HomeViewModel.ktapp/src/main/java/com/pinakes/app/ui/screens/search/SearchFilterSheet.ktapp/src/main/java/com/pinakes/app/ui/screens/search/SearchScreen.ktapp/src/main/java/com/pinakes/app/ui/screens/search/SearchViewModel.kti18n/de.jsoni18n/en.jsoni18n/fr.jsoni18n/it.json
CodeRabbit (#25): HomeViewModel read features.features.value.catalogueMode once, so a /health that resolves after the first shelf load — or a runtime lending<->catalogue switch — didn't re-drive the shelf, leaving it filtered/labelled for the wrong mode until a manual refresh. Now refresh() is driven by features.features.map { catalogueMode }.distinctUntilChanged() (collectLatest, so a flip mid-flight abandons the stale re-drive and distinctUntilChanged avoids a network storm), and observeCache() combines the cached-catalog flow with the same flag flow so the offline fallback re-filters too. compileDebugKotlin clean.
1 participant
Addresses Uwe's in-app remarks (a real lending-library user): the opening list had no heading, results were only sortable by cataloguing date, and there was no sub-category filtering.
What's new
sort=toGET /api/v1/catalog/search(backend support: Pinakes PR #242). Changing sort resets pagination. The active order is shown as "Sort: " in the results header.genreid, which the API matches at any level). Each level is labelled "Within ".Reviewed + hardened
Ran an adversarial multi-lens review on the diff; all findings fixed in the same branch:
loadMore/search could append a stale-sort page + restore a mismatched cursor → a generation counter now drops superseded results.stateDescription/selectedsemantics.genrePath()depth cap (StackOverflow guard)../gradlew :app:compileDebugKotlinbuilds clean. Not yet built to an APK / run in the emulator.Summary by CodeRabbit
New Features
Bug Fixes