Publications page: add an "All" option to the page-size selector (10 / 20 / All)

[jcschaff]

Requested by Michael Blinov: the webapp publications page should let you page through the
list with a limit of 10, 20, or ALL.

Where this stands today

Two thirds of it already works. publication-list.component.html:83 has:

<mat-paginator [pageSizeOptions]="[10, 20]" showFirstLastButtons></mat-paginator>

so the live page at https://vcell.cam.uchc.edu/publications already offers 10 and 20 (verified
in the deployed prod bundle, not just in source — the [10,20] literal is in
main.5a5f507e03ee6297.js). pageSize is not set, so Angular Material falls back to the first
option and the page opens at 10 per page.

The missing piece is the "All" option. Prod currently has 250 publications, so at 10 per
page that is 25 pages to scroll through when you want to scan or Ctrl-F the whole list.

Why this is cheap

The component already fetches the entire list up front and pages it client-side:

this.publicationService.getPublicationList().subscribe(data => {
  this.publications.data = data;          // MatTableDataSource
  this.publications.sort = this.sort;
  this.publications.paginator = this.paginator;
});

So "All" is a display change only — no REST change, no extra round trip, and nothing to add to
/api/v1/publications. Everything is already in the browser.

Things to decide while implementing

• How to express "All" to MatPaginator. It only takes numbers, so the two usual routes
  are: put the row count itself in pageSizeOptions and relabel it via a custom
  MatPaginatorIntl, or use a sentinel (e.g. Number.MAX_SAFE_INTEGER) displayed as "All".
• Keep it correct under filtering. The page has a Filter box that drives
  MatTableDataSource.filter, so the row count changes as you type. If "All" is wired to a
  fixed number it will go stale; whatever approach is chosen should still show every matching
  row.
• Default page size. Worth confirming with Michael whether the page should still open at 10
  or remember the last choice.

What we do not know

Michael asked for this specific behaviour, not for the problem behind it. Second-hand, the
goal appears to be getting every record on screen at once so he can copy and paste the whole
list, or search it for text. That reading is inferred, not confirmed by him — worth a two-minute
conversation before anyone designs around it, because the three plausible goals pull in
different directions:

• Copy/paste the whole list. "All" solves this, and it is the reason to just build it. A
  selection of 250 rendered rows copies cleanly into a spreadsheet or a document. If what he
  actually wants is the data in a file, a CSV/TSV export button would serve him better than a
  long page — there is no export anywhere in the webapp today, so that would be new work rather
  than a tweak.
• Search for text. Partly solved already, and this is worth telling him: the Filter box
  searches all 250 records, not just the current page — MatTableDataSource.filter applies
  to the full data set and the paginator then pages the matches. What "All" adds is that the
  browser's own Ctrl-F works, since Ctrl-F can only see rendered rows. If he has been assuming
  the Filter box only searches the visible page, the feature he needs may already exist.
• Scanning / reading the list. A longer page helps, but so would sorting and column choices;
  no way to tell which he means without asking.

None of that is a reason to hold up the "All" option — it is a small, harmless display change
that does what he asked, and it is the honest response to a specific request. It is a reason to
ask him what he was trying to do before building anything larger on top of it.

While in here it may be worth asking him whether the same selector is wanted on the other
listing pages, so they behave alike.