There are 3 types of “paging” mechanisms which we may want to use, depending on product / table:
Default: “Load more” CTA
A more minimal expand mechanism that can work in 2 different ways:
- toggle between a predefined excerpt (e.g. 10 items), and displaying everything
- reveal a predefined number of rows in addition to the ones currently visible (e.g. add 10 more rows)
Optionally, indicate how many items there are in total. Examples:
Showing 10 of 274 items. [Show all]
Showing 20 of 274 items. [Show 10 more]
Pagination
Proposal: strip borders from the existing Vanilla pagination pattern.
Preferred alignment: right. Depending on whether the table is grouped, on some breakpoints the left-most edge may not be the strongest keyline. For example, in the mockup below, the Model column forms the strongest keyline. Aligning the pagination to the left would cause it to cross the keyline. Aligning to the right would avoid this kind of issue.
Pagination within groups should be avoided. Use the “Load more” pattern instead.
Pagination should optionally support key bindings, maybe when the mouse is over the table?
Virtual scroll
A defined number of rows is visible when the page loads. On scroll, more rows are loaded. Exact triggers to be defined in prototyping stage (should you load when nth row hits the top of the window? Top of container if scrolling within? etc. ) We may want different row height, if possible.
From previous discussions, we know one of the reasons not to use this more is the lack of a div implementation of the table in Vanilla. A div reference implementation has been requested by Kit/Huw/Caleb, before.
Pagination per grouping type
Paginating within a group should default to the “load more” CTA above