The goal of this project is to replace the current pagination system by infinite scrolling to accommodate a better user experience. This is a significant change to the current structure which requires the users to press buttons multiple times when moving across the data set. This especially impacts operations that tend to bring users back to the first row of the data set, after which, moving to another part becomes a cumbersome task requiring multiple clicks of the next button.
The main pull request for the project with a brief outline of the steps is here: #2746.
-
The first step of this project was to restructure the data-grid to maintain sync between the header columns and the table body. The work done on this issue is described in this pull request: #2719.
-
The rendering of rows and cells used expensive jQuery operations that can be replaced with native javascript to improve the performance. The corresponding pull request is here: #2973.
A part of the project was to ensure that the position of the data set does not change in operations which do not affect the grid directly. The two operations that we mainly discussed were Facets and Reconciliation.
-
Restructuring of facets to a class-based structure was added through this pull request: #3097.
-
Here is a link to the weekly blogs that explain several ideas and the work.
The project uses the virtual scrolling concept to implement infinite scrolling. It can delete row elements that move out of the view while maintaining a fixed number of visible rows at a given time. This is implemented by dividing the rendering functions into three parts:
- When the user scrolls downwards and a checkpoint row becomes visible (namely, the
load-next-setrow) which further fires off the function that renders the next set of rows. - When the user scrolls upwards and crosses the checkpoint row, it further fires off the function that renders the previous set of rows.
- When the user scrolls quickly in any direction. This uses a timer to call the function which calculates the page number corresponding to the scroll position and then renders the corresponding rows.
When the data set is initially loaded into the grid, the scroll bar height is calculated using the average height of visible rows and the total number of rows in the project. At any given time, the scrollbar position denotes how far the user has traveled through the data set. This position is maintained using one empty row at the top of the data set and another at the bottom. Every time a new set is rendered, changes to the height of these two rows are made according to the relative position of the first rendered row in the visible set with respect to the total number of rows in the data set.
The PR requires some additional changes before it can be merged. Following are the changes:
- Adding tombstones when rows take longer to load.
- Dealing with cases where the screen size is larger than the set page size.
- Increasing the performance of rendering by using templates to reuse the same Document Object Model (DOM) elements for new rows.
Supplementary additions: