Switch to infinite scrolling

[blizzz]

Contributes to #941

Subsequent to #1508

With the infinite scrolling approach we like to dissolve the traditional pagination display and controls.

We want to show up to 300 rows at the same time, with initially 100. When scrolling down, already cached rows will be blended in, while the next results are being loaded in the background. If the more than 300 elements would be visible, the top elements in the DOM will be removed again.

Therefore we have to have similar – reversed – logic for scrolling up.

We should limit the number of rows that are being kept in runtime cache to avoid consuming too much ram in the browser. Unfortunately it is not known how much RAM is available. A hard set of numbers of rows is not ideal, as rows can have very different payloads and differ in size. Thus a dynamic approach is preferable with setting a limit of 250MB (currently, a tab with 10k rows loaded consumes 1GB for me). Ideally testing with a mobile browser on an average phone should be taken into account.

On partially loaded tables, setting a filter or a sort order would need to fetch the rows from the server and re-initialize the state. A load animation - which we have when switching tables/views – should reflect this.

[enjeck]

Why is infinite scrolling better than pagination? Is it just a UX decision or is the performance better? Would caching pagination (if possible) be the same performance-wise?

[blizzz]

Why is infinite scrolling better than pagination? Is it just a UX decision or is the performance better? Would caching pagination (if possible) be the same performance-wise?

Just UX, more modern. The underlying data keeping and fetching does not change much. We can also have pages preloaded with pagination controls. It was also the long term goal and idea of our pagination approach, the current one was a quick first solution.

[blizzz]

… what I did not think of though where the Applications/Contexts. There the infinite scrolling approach does not make much sense, with several tables or views present. You might scroll to death to reach just the next table or view… With the layout it would be difficult to scroll by, maybe it would be beneficial to keep the paginated view for this part at least.

[xbluemonkx]

… what I did not think of though where the Applications/Contexts. There the infinite scrolling approach does not make much sense, with several tables or views present. You might scroll to death to reach just the next table or view… With the layout it would be difficult to scroll by, maybe it would be beneficial to keep the paginated view for this part at least.

you could add "internal scrolling". so every table on a view has a maximum rows to show (maybe add an expand button to show more). now you can scroll within the table to see more lines or move the cursor out to scroll the page itself to get to the next view.