Pagination
Some EUI components have pagination built-in, like EuiBasicTable, but for custom built paginated interfaces you can use EuiPagination manually.
Component
EuiPagination accepts a total pageCount and only shows up to 5 consecutive pages, with shortcuts to the first and/or last page. It also requires the parent component to maintain the current activePage and handle the onPageClick.
Accessibility recommendation
Provide a descriptive aria-label for each pagination set.
Usage
Few pages
The UI simplifies when we have fewer than the maximum number of visible pages.
Centered pagination
You can use EuiFlexGroup to center the pagination in a layout.
Compressed and responsive
Use the compressed prop to minimize the horizontal footprint. This will replace the numbered buttons with static numbers and rely on the first, last, next and previous icon buttons to navigate.
This is also the same display that will occur when responsive is not false. You can adjust the responsiveness by supplying an array of named breakpoints to responsive. The default is ['xs', 's'].
Indeterminate page count
If the total number of pages cannot be accurately determined, you can pass 0 as the pageCount. This will remove the button numbers and rely solely on the arrow icon buttons for navigation. Without a total page count, the last page button will pass back -1 for the activePage.
Table pagination
You can use EuiTablePagination to create a combination "Rows per page" and pagination set, commonly used with tables. If you pass 0 in as one of the itemsPerPageOptions, it will create a "Show all" option and hide the pagination.
Custom pagination
Or you can use EuiFlexGroup and EuiContextMenu to set up your own custom pagination layout.
Guidelines
Lead with filters and search
For any results-style table, always provide ways to filter and search for content, first and foremost. Pagination is most effective after the user has reduced the number of results from thousands to hundreds of records, for example.
Display total results separately
When possible, always present a clear indicator of how many (and if not all results) have been returned. Just a simple count will do. Including a detailed summary of results at the top of the table or list goes a long way to signify what paging can’t.
Indicate indeterminate results
If you cannot provide a concrete number of results, you still have to communicate what the current results showcase. For instance, say "Showing first 100 results" or "Search results maxed at 1000" or "Results fetched at runtime".
Remember that not all users understand how your data API works. They just care about the data that's being shown to them.
Give users control
Providing a “Rows per page” option is often helpful enough to provide users control over the amount of data they see at once.
Keep the choices simple and only show “Rows per page” if there are more rows than the smallest option. For example, if there are only 9 rows and the smallest option is 10 rows per page, hide the selector.
Do: For shorter sets of data, you may want to include an “Show all” option.
Don't: Overload the user with choices, stick to only 2-3 options.
Optimize defaults
Most users don’t customize the default view. Therefore, it’s vital that you provide optimal defaults and reduce complexity as the number of entries increase. This means choosing a default “Rows per page” that best corresponds to the total results. For instance, 1000+ results shouldn’t start with 10 rows per page, but rather 20 or 50.
Here are some samples of what controls to provide based on the number of data entries.
Total entries | Rows per page options | Pagination style |
|---|
