The team identified the need for a pagination component during the review of the design specs for Read-Only Tables. The team decided to add pagination to read-only tables during the May 19th team meeting. The team chose pagination against the original requirement of having infinite scrolling to prevent issues with real-time data causing data duplication.
The pagination component contains the controls for navigating across the parts (pages) of records from a table that the UI can’t fully display. It usually sits at the bottom of a table.
The pagination component is always visible, even if the table does not reach the number of records required to be split into parts.
The pagination component controls are:
The scrolling settings of the table should allow the pagination component to be fixed at the bottom.
In this figure, the two red horizontal lines delineate the scrolling area.
The ideal number of records per page will depend on the desired user experience. For real-time data, the minimum may be several thousand. For most tables, pagination won’t be required as most data will fit on a single page.
What are reasonable max and minimum page sizes?
Based on discussion with the team, the first version of the read-only table will use offset-based pagination. This is the preferred choice as it is already implemented and does not prevent the roadmap from being built and allow other methods to be used later.
Some of the following points were discussed and shall be reconsidered later when we have more evidence of limitations imposed by our current pagination method:
Please see “Pagination options” on GitHub Discussions for more detail.