peter/siftlode
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(search): keep scrape-sourced YouTube results across a reload

Browse source 
A live YouTube search was always dropped on reload so it could never
re-spend quota. But the default scrape source costs no quota, so there's
no reason to bounce the user back to the feed — they can stay on their
results.

Feed now stamps history.state._ytScrape=true once a search resolves via
the scrape source; App restores _yt on reload only when that flag is set
(and re-runs the search, which is free). An api-source search is left
unmarked and still drops to the feed on reload, since re-fetching it would
cost ~100 units. The flag is cleared when a new search starts (Feed
re-stamps it once the new results' source is known).
This commit is contained in:
npeter83 2026-07-01 01:55:05 +02:00
parent 703ae41f2d
commit b498755067
2 changed files with 33 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

12
frontend/src/components/Feed.tsx
View file

@ -151,6 +151,18 @@ export default function Feed({
retry: false,
});
// Remember (in history.state) that this live search was served by the zero-quota scrape source,
// so a reload restores the results instead of dropping to the feed — re-fetching scrape pages
// costs no quota. An api-source search is left unmarked (a reload would re-spend ~100 units).
useEffect(() => {
if (!ytActive) return;
const st = window.history.state;
if (!st || st._yt !== ytSearch) return; // only mark our own sub-view entry
if (ytQuery.data?.pages?.[0]?.source === "scrape" && !st._ytScrape) {
window.history.replaceState({ ...st, _ytScrape: true }, "");
}
}, [ytActive, ytSearch, ytQuery.data]);
// Switching to the relevance sort when a search starts happens atomically in the header's
// input onChange (race-free with the query update). Here we only handle the reverse: when
// the term is cleared, fall back to the default sort — relevance has no dropdown option and