Current behavior
When a user scrolls, it fetches RowStates only when they stop scrolling. Then it starts to fetch everything up to 100 records towards last non-scrolled record. If a user scrolls one-direction with interruption, they always have to wait for a long time to fetch up to 100 records. No records in advance is fetched, too much records in backward direction, which is useless if a user doesn’t changescrolling direction.
The goal is to provide a seamless scrolling behavior.
Ideas to implement:
The goal is to make scrolling and using scrollbar seamless and communicate pending row state fetching transparently to users. The following are just ideas.
Solution 1 (asynchronous loading)
- fetch only what user can see,
- if a user stops scrolling, fetch one page in advance and 1 page before a user can see (preemptive behavior)
- fetch immediately, do not wait for user to stop scrolling - user can scroll slowly for a very long time, fetch by small chunks. Rowstates backend call has linear complexity, so it doesn’t too much matter if it’s loaded together or by chunks. There is a network overhead of course, so it’s not ideal to have too small chunks. It could behave worse on a slow network connection, especially on a connection with a long ping value.
- show (visualize, communicate to a user) incomplete row states at actual row somehow so that it’s clear what rows are pending to load
Solution 2 (without asynchronous loading)
- keep waiting for a user to stop scrolling before issue the call to RowStates
- fetch only what user can see in the current view port.
Solution 3 (without asynchronous loading, configurable in the model)
- keep waiting for a user to stop scrolling before issue the call to RowStates
- fetch only what user can see in the current view port plus M page ahead and N page before. M and N would be configurable at the model menu reference, default value 0 for both parameters.