library-search-request-fanout

# Make the library search fast

Typing a search into the library takes about 28 seconds to settle.

Make it fast without changing what the page shows:

- **At most three requests per change.** Typing a term and pausing, clearing
  the search, or ticking or unticking a sidebar filter should each send at
  most three requests to the server in all, so every sidebar list's first
  page has to come from one request. The lists must show the same options,
  counts and order as they do today.
- **Cancel all the way down.** The page must cancel the requests a newer
  change makes obsolete, and when a request for rows, points or list counts
  is aborted, by the page or by any other client, its database query must
  stop as well.
- **No stuck grid.** Changing the search again while the grid's rows are
  still loading must never leave the grid stuck loading.
- **The URL is the only copy of the page's state.** Keep the search, the
  sidebar filters and ranges, the grid's sort and column filters and the
  compare picks in the URL alone, and show whatever the address says: on a
  link opened fresh, after Back or Forward (coming back to the library from
  another page of the app included), and after one of the app's own links
  changes it. Links that work today must keep working, and picking or
  unpicking a model to compare must not reload the grid, the lists or the
  scatter.

No search may change which rows, points or list counts the page shows or
the existing `/api/library` endpoints return.

## Environment

PostgreSQL on localhost:5432 and the local database endpoint the app's
driver uses are running when you start, and the dev env files point at the
dev database, which is migrated but holds no catalog. The model files the
library opens live on Azure File Shares, which are not reachable from here.