chadtmiller.com/knotless

Switch repository

Loading…

What changes

Going back to code search, from a file opened after "More files", shows every file loaded before, at the place it was left, rather than the first 20 at the top.

Pages, the helper behind every "More …" button, has capture and restore for a page's SvelteKit snapshot: the pages added below the first and where the page was scrolled to, kept with the history entry. The search page exports one. SvelteKit scrolls back before it restores a snapshot, while the page holds only its first page, so the scroll is cut short; restore scrolls again once the files are drawn.

Why

Loading more and then opening a file lost all but the first page on the way back. Keeping the count in the address (?n=60) was the other way: it would ask the server for every page again on each return, and limit stops at 50. A snapshot asks for nothing.

How it was checked

In Chromium over the recorded answers, with a second page given: the first page drew 12 files, "More files" 24, a file opened from the last, and back showed 24 again at the same scroll (6285 before and after; 2972 before restore scrolled again). npm run check passes. Nothing the shots draw changes.

Shortcomings

The other pages with "More …" (tags, releases, notifications and the rest) can take the same snapshot in a line each; this does the search page alone.

🤖 Generated with Claude Code

This adds capture and restore to Pages and exports a SvelteKit snapshot from the search page. Going back to code search then redraws the files loaded after "More files" and scrolls to where the page was left. I read both changed files and the whole of pages.svelte.ts, and found nothing that must change.

• restore anchors the kept pages to #first.items, the same identity #added checks. If another load of the route has replaced the first page by then, the kept pages are dropped instead of shown against the wrong list.
• The snapshot holds only plain items, a cursor and a number, so it serializes safely.
• The tick() followed by scrollTo matches the problem the body describes, SvelteKit scrolling before it restores.

The pull adds no test for this. The body says it was checked in Chromium by hand, and web/AGENTS.md may want an e2e flow for it. I did not read that file, so that is a suggestion only.

Pushed two commits to this branch: main merged in, and the search page's snapshot formatted as oxfmt does. The web check (format) failed three merge-queue batches on it, since queued pulls run only check and test before batching. Pull the branch before pushing more here.

Since the approved commit, the pull's own change is a reformat of the snapshot export in web/src/routes/search/+page.svelte, which behaves the same. Everything else in the diff since then comes from the base merged in, so it isn't this pull's change and I didn't review it. My earlier approval stands. My earlier note about an e2e flow was a suggestion only, and nothing needs to change for it.