Grid Table: Same Request Sent Over and Over Again

URL (minimal example if possible):

embed.plnkr.co/ZnEpcAy5iKaukNXd

Given

• A grid table (sap.ui.table.Table) having rows aggregation bound with Northwind’s /Customers. The service leverages server-side paging ("__next").
• Low number of Table’s threshold.

Steps to reproduce the problem:

1. Open the above example page and wait until the preview panel is loaded.
2. Once the initial entries are loaded and the focus is set on the first row, press <kbd>Ctrl + End</kbd> to scroll to the end of the table. Do not scroll up afterwards.
3. Wait until any entries are loaded in the scrolled area… forever.

What is the expected result?

The table gets filled in the visible rows.

What happens instead?

• Requests are sent constantly and which never stops. I waited for around an hour until the browser ultimately crashed (Probably due to highly accumulated memory footprint).
• If table’s enableBusyIndicator is set to true, the user cannot even scroll up anymore due to the busy indicator blocking all user interactions. Only when the user scrolls up until the previously loaded entries are visible, the table starts to get filled properly.

Any other information? (attach screenshot if possible)

I guess this behavior has something to do with the fact that the grid table involves both server- and client-side paging. Whether it’s an anti-pattern or not shouldn’t be a matter of this issue though.

^{Network trace showing the same request being sent over and over again}

[Thodd]

See also: https://github.com/SAP/openui5/commit/2005ea049891ed661349524681fd2abbb89c1db3

[Thodd]

Hi guys,

So the endless loop should be fixed, as we have reworked the $skip/$top value calculation.

The Northwind responds with a set of max. 20 entries and a __next link, even though the request sent by the ODataListBinding contains a $top value of 60. We know that this can happen, and the approach of the ODataListBinding is to ignore the __next link, and keep on sending consecutive requests with adapted $top and $skip values. This is ok, since following __next links also ends up in multiple requests to satisfy the original data request by the table.

Though if you aim for a productive scenario the mix of our $skip/$top based paging and the Northwind’s __next paging mechanism is suboptimal, as it will end up in multiple requests, which cannot be optimized as easily.

I would not advice to use such a mix in a real-life scenario.

Ideally you should just use a regular $skip/$top based paging. The Northwind also offers other collections, which will fully respect $skip/$top, e.g.: https://services.odata.org/V2/Northwind/Northwind.svc/Product_Sales_for_1997?$skip=10&$top=60&$format=json

At the moment we have no intention to implement a server-side paging based on __next links, but of course contributions are welcome and appreciated if anyone out there wants to tackle this.

BR, Thorsten