perf(library): prefetch inactive tabs so switching feels instant

[InstaZDLL]

Summary

User-reported pain: clicking Artistes / Albums / Morceaux for the first time leaves the user staring at a blank tab for 1–2 s while the backend runs the corresponding list_* query and the JSON crosses Tauri's IPC bridge. Subsequent visits to the same tab were already instant — each tab's state array persists across activeTab switches — but the cold-cache first click was painful.

Approach

Reshape the loading logic in LibraryView so the user only pays the fetch cost once per cache-invalidation, regardless of which tab they click first:

1. tabCacheKeys memo — derives one stable key per tab from the inputs that legitimately invalidate its data (library set, sort, filterNoCover, cover-reload signal, edit signal).
2. loadedKeysRef — records which key currently lives in each tab's state array. The foreground loader short-circuits when the active tab already matches its desired key (e.g. the user clicked back to a tab that just got prefetched).
3. Background prefetch effect — waits 200 ms after the active tab settles, then serially fetches each non-active tab whose stored key is stale. Serial (not parallel) so a large list_tracks query doesn't fight the active tab for SQLite pool slots.
4. fetchTab / applyTab helpers — centralise the per-tab switch so the two paths can't drift apart on the next refactor.

Net effect

• The very first foreground tab loads exactly as before.
• Every subsequent tab switch renders the cached data instantly.
• A silent refresh runs in the background only when the cache key has actually invalidated (sort change, library change, edit, etc.).
• Failures in the background path are swallowed and fall back to the foreground loader on user click — no regression on the worst case.

Test plan

• bun run typecheck
• bun run lint
• Cold launch → first tab (Songs/Tracks) loads normally → click Albums within 200 ms+~query time → instant render
• Change sort on Albums → background prefetch refreshes other tabs (verify by switching back to Songs and checking the data picks up the same editRefetch/sort changes)
• Edit a track in Library → all tabs visible data refreshes within ~200 ms after the foreground load

Summary by CodeRabbit

• Refactor
  • Optimisé le chargement des onglets de la bibliothèque avec des mécanismes de mise en cache améliorés et une pré-récupération des données en arrière-plan, offrant une navigation par onglets plus fluide et réactive.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4740bc6f-e7a4-4ef3-bd03-a91861d4167b

📥 Commits

Reviewing files that changed from the base of the PR and between 77bad0a and 5061aa6.

📒 Files selected for processing (1)

• src/components/views/LibraryView.tsx

---

📝 Walkthrough

Walkthrough

LibraryView implémente un système de cache par onglet avec des clés de cache dépendant des libraries, tris et filtres. Le chargement foreground ne recharge l'onglet actif que si sa clé a changé. Une pré-récupération background charge les autres onglets après ~200 ms avec gestion d'erreur silencieuse.

Changes

Système de cache par onglet et préfetch background

Layer / File(s)	Summary
Calcul des clés de cache et chargement foreground src/components/views/LibraryView.tsx	Ajout de useMemo pour le calcul des clés de cache par onglet. Factorisation des fonctions fetchTab et applyTab. Le useEffect foreground charge l'onglet actif uniquement si sa clé de cache n'a pas déjà été appliquée (vérifiée via loadedKeysRef).
Pré-récupération en arrière-plan src/components/views/LibraryView.tsx	Ajout d'un useEffect de préfetch déclenché après ~200 ms : sélection des onglets inactifs à cache invalidé, requêtes en série, mise à jour des états via applyTab, et stockage dans loadedKeysRef. Les erreurs sont ignorées (fallback au rechargement foreground au clic).

Estimated Code Review Effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🚀 Cache keys calculées, onglets en mémoire,
Foreground charge, background prépare,
Délai optimal, erreurs pardonnées,
LibraryView respire enfin ! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	Le titre suit le format Conventional Commits avec le scope « library » en kebab-case et décrit clairement l'objectif principal : optimiser le chargement des onglets inactifs pour accélérer les changements d'onglet.
Description check	✅ Passed	La description couvre le problème utilisateur, l'approche technique, les résultats nets et inclut un plan de test. Tous les éléments clés du template sont présents (summary, approach, test plan), bien que certains tests manuels ne soient pas coché comme complétés.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch perf/library-tab-switch-instant

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[InstaZDLL]

Reverting — I misread the original complaint. Daisy said the tab itself opened instantly and only the artwork flickered for 1-2 s. My prefetcher kept SQLite busy in the background, so when the user clicked a new tab the foreground fetch queued behind a slow list_tracks/etc. and the perceived lag got worse. Closing without merging and tackling the actual issue (artwork load smoothness) in a separate PR.