ListGrid warning for large rows in "paged" dataFetchMode

[vvab]

Hello,

We use SmartClient Version: v10.0p_2016-02-15/Pro Deployment (built 2016-02-15)

We see the following warning in the smartclient dev console in one of our "paged" ListGrids which fetches 75 rows at a time. drawAheadRatio is 1.

----
WARN:This grid is showing 2,275,808 rows. Due to native rendering limitations, grids with this many rows may not appear correctly on all browsers. Consider filtering the data displayed to the user to reduce the total number of rows displayed at a time. This will improve usability as well as avoiding unpredictable behavior.
---

Can you help us understand this warning. Since we fetch 75 rows at a time and the data is "paged" - what is the meaning of this? Does this indicate that Grid would pre-draw all the 2,275,808 rows, even though showing only the data for 75 rows at a time? That would defeat the purpose of paginating, is n't it?

In essence, we want to show all our data 1 page (of 75 rows) at a time. There is no filter we can apply here.

[Isomorphic]

We're only rendering the visible rows. The problem is that the browser does not allow us to create the blank space required for 2 million rows, which is necessary for allowing the user to drag the scrollbar and jump into the middle of the dataset.

But as the message implies, this capability is generally useless to the user since it's impossible to drag a scrollbar and land with any precision in the middle of such a huge dataset. You'll also find that it's very very slow to select 75 rows somewhere toward the end of a 2+ million row dataset.

Hence it makes sense to offer some kind of filtering interface rather than throwing the entire dataset at the user.

Another possibility is to use the progressiveLoading pattern - see operationBinding.porgressiveLoading.

[vvab]

Thanks. This makes sense and we do use progressive loading since earlier when we were at smartclient 8.3. The above message in dev console was received when we tried to debug some odd scrolling behavior with Smartclient 10.0. As part of debug when we advertised the actual rows available in db, this message was seen.

The odd behavior we see is this and hope you can help provide some insight into what might be going wrong- as part of progressive loading we advertise 10 extra pages as part of the DSResponse (of course only advertised if there are more records in DB greater than (endRow+1). This had been working fine in smartclient 8.3, but since the time we have upgraded to 10.0, the scrolling has been odd and inconsistent. Sometimes user scrolls to the 'end' of the resultset on the grid, request goes correctly to backend and provides the right response - with 10 more pages advertised if there is more data still. However, the rendered area on the grid shows empty. Scrolling back up shows data which is the rows fetched in the latest scroll. Our expectation is that it should render these rows and not render the empty subsequent rows which are as a result of the advertised extra rows.

The latest on this is that, seems like advertising only 1 extra page in the response seems to make the behavior a little better, but we are not sure if this is the 'fix' as the nature of the problem is so inconsistent. Still trying to wrap our heads around it. Any help and input is very much appreciated. We were advertising 10 extra pages to have a more user friendly scroll as otherwise the scroll bar appears way at the bottom of the grid.

[Isomorphic]

What we'd advise is to make sure you aren't omitting startRow or endRow values in your responses, and aren't doing something like sending back a row range that is smaller than what the grid requested when this problem occurs.

Next time it happens you should look carefully at what the situation is: with the grid showing a blank area, what rows are returned from getVisibleRows(), what was the last requested row range to the server and what startRow/endRow were returned in your response, and if you directly look at the ResultSet using APIs like rowIsLoaded(), were the returned rows actually placed into cache as expected? That should clear up how you can be in the situation of the grid looking at a blank area but not requesting new rows.