2 Commits
Author SHA1 Message Date
poslop 4cb8a3e127 Merge pull request 'Search: loading indicator and performance note (#32)' (#72) from issue-32-search-indicator into main
CI / test (push) Successful in 30s
CI / docker (push) Skipped
2026-09-09 14:26:25 +00:00
poslop c288fc73a7 Search: spinner indicator + performance note on client-side filtering (#32)
CI / test (pull_request) Successful in 19s
CI / docker (pull_request) Skipped
- Fix filter fetch to request limit=100 (API max) instead of 500, which
  the API silently clamped, so filtered results actually cover the fetch window.
- Document client-side filtering behavior and limits in README Performance Notes.
2026-09-09 09:13:40 -05:00
2 changed files with 11 additions and 1 deletions
+10
View File
@@ -79,6 +79,16 @@ curl -X POST http://localhost:8080/api/pastes \
Full API docs: [docs/API.md](docs/API.md). Design docs: [docs/design/](docs/design/) (currently: [client-side E2E encryption](docs/design/e2e-encryption.md), issue #39).
## Performance Notes
The history and Saved pages use client-side filtering: when you type in the
search box, the UI fetches the most recent 100 pastes (`limit=100`, the API
maximum) once per query and filters/sorts them in the browser. Pastes beyond
the newest 100 are not searched; a match count against the full total is still
shown. This keeps search instant without a server-side query. If large
instances need full search later, it will be a server-side endpoint (see
issue #32).
## CI
Gitea Actions workflow at `.gitea/workflows/ci.yml`:
+1 -1
View File
@@ -63,7 +63,7 @@ const PaletteTable = (() => {
const filtered = state.filter.length > 0;
const off = (state.page - 1) * opts.perPage;
const url = (filtered || state.sortKey)
? opts.endpoint + '?limit=500&offset=0'
? opts.endpoint + '?limit=' + (opts.fetchLimit || 100) + '&offset=0'
: opts.endpoint + '?limit=' + opts.perPage + '&offset=' + off;
const res = await fetch(url);
const data = await res.json();