Fixes on Add New about results that don't belong to the search on screen, and the search state that let it happen. It started as a small quality-of-life fix (#1052 and #1053, combined here); the review showed the cause was how the page owned its search, so the last commits rework that instead of patching each case.
1. An empty search left the previous results on screen
Search for a book (say 16 results), then search for testwkledjhfg: the No results found toast appears, but the 16 books and the Found 16 Books heading stay under the new query, as if they were its results.
handleUnifiedSearchResults hands non-empty results to handleSimpleSearchResults, which resets the result state first. On an empty result it only cleared the status and error and showed the toast, so titleResults, totalTitleResultsCount, allAudibleResults and audibleResult kept the last search's values. The empty branch now clears them, the same way handleSimpleSearchResults and handleAdvancedSearchResults do before showing their own empty-result toast. (42659fb)
2. The last search came back on every visit
The page kept its last search in localStorage (results, count, search type, resolved ASINs and the advanced form), so it came back on every visit: the next day, after restarting Listenarr or the browser, with no search done. The persistence was added to keep the search while going to a book and back (7cb8135, "Add persistent search…"); this keeps that and limits it to the session. (d9cffff)
sessionStorageinstead oflocalStorage, with the same keys: the last search survives navigation in the tab, not closing it.- What earlier versions left in
localStorageunder these keys is removed and not shown.
3. A search belongs to the app, not to the page
- Only a successful search is kept. Starting a search empties the previous one, on screen and in the session; its parameters are saved only once its res...
Automated Canary build