search

SAP / openui5

OpenUI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice.
http://openui5.org
Apache License 2.0
2.95k stars 1.24k forks source link

sap.ui.table.Table: Threshold ineffective on initial load #2643

Closed janmattfeld closed 2 years ago

janmattfeld commented 5 years ago

OpenUI5 version: 1.60.16 (possibly any other) Browser: Chrome 76.0.3809.100 (Windows 10 x64 10.0.18362) Any other tested browsers: Also fails in Edge and Internet Explorer 11 Minimal example: https://output.jsbin.com/manuqavuvu/1 (Disable CORS!)

Steps to reproduce the problem:

  1. Use sap.ui.table

    • threshold = 500
    • visibleRowCountMode = Auto

  2. Query a larger OData v2 data source

What is the expected result?

The table immediatly fetches data for the first 500 rows. Thus, enabling smooth scrolling through a large portion of these entries without further interruption as described in the API documentation for the threshold property.

What happens instead?

The table fetches additional data way to early, in some cases right after the first or second scrolling. During the fetch, the table's local busy indicator is displayed, preventing all user interaction. This becomes really annoying if the query actually takes time and blocks the user from scrolling through the remaining 80% of the already loaded data.

Network trace of the minimal example immediately after displaying the table:

  1. GET Orders?$skip=0&$top=505 (Correct)
  2. GET Orders?$skip=200&$top=500 (What now?)
  3. GET Orders?$skip=400&$top=430 (No idea)

This might or might not be related to the OData test service. Yet, the symptoms are identical using on-premise SAP Gateway services.

ThomasChadzelek commented 5 years ago

Hello @janmattfeld !

I understand that you are using OData V2 and I cannot immediately help there. My team is doing OData V4. Nevertheless I would like to better understand your scenario. You say that the 2nd GET blocks the UI and prevents further scrolling? How does that look like for the end user; I mean, is there a wait cursor or what happens?

Best regards, Thomas

janmattfeld commented 5 years ago

HI @ThomasChadzelek,

Thanks for your prompt reply.

The table switches into a local busy state, preventing all user interaction (showing the local busy indicator only). I updated my initial issue description.

Thanks, Jan

ThomasChadzelek commented 5 years ago

Hello @janmattfeld !

Thanks for the clarification. Looks like we have a similar issue with V4. We will fix that, but my team cannot fix the V2 issue. I will see how I can help to dispatch this question.

Best regards, Thomas

janmattfeld commented 4 years ago

Hi @ThomasChadzelek ,

did you have a chance to dispatch the issue?

Thanks, Jan

ThomasChadzelek commented 4 years ago

Hello @janmattfeld !

Sorry that we did not respond for so long. Looks like I immediately dispatched the issue, but my colleague did not find the time to look at it so far. Good news it that Patric has now taken over and I trust him to take care. Stay tuned!

Best regards, Thomas

Jordan-Ryan commented 4 years ago

Hi,

I am running on version: 1.60.24

I have a very similiar issue, on inital load it calls the service for 113 records (13 visible and 100 threshold) but when I scroll down (past the 13 records) it starts to call the service again, meaning the busy indicator comes and the table is not usable.

Would this be the same issue as mentioned here or would this be slightly different?

janmattfeld commented 4 years ago

That sounds like the exact same issue. Thanks for sharing!

Jordan-Ryan commented 4 years ago

That sounds like the exact same issue. Thanks for sharing!

Thanks. Mine isn’t doing the issue where the threshold changes though. So skip and top seem fine. So it then goes skip 113 top 100 skip 213 top 100. Which is why i asked if it was covered under the same bug.

Is there any solution for this I’m thinking maybe on before rebind table. We can quickly close the busy indicator and the table state. That way it fetches the next 100 when its 100 away (hopefully then when the user gets there its already loaded). Only issue then, is if they use the scroll bar it wont be very intuitive to show its loading data.

janmattfeld commented 4 years ago

top and skip are not my main concern, though. What bothers my users most, is activating the busy indicator too soon, while there are still records that could be shown.

I disabled the local table busy indicator completely. That seems to be the same effect your event listener to rebinding would do, right? But that of course leads to awkward situations, when the next data is loading but on the UI nothing seems to happen.

So, the fix should probably be UI5-internal, as all workarounds to this point failed.

Shtilianova commented 4 years ago

Hello @janmattfeld , I've created an internal incident 2080375757. The status of the issue will be updated here in GitHub. Regards, Diana

karm31 commented 3 years ago

@Shtilianova Hi any update on this issue? I am facing the same issue,

Regards Karm

uhlmannm commented 3 years ago

Hi,

unfortunately, the issue could not be resolved so far. We are internally tracking this as FIORITECHP1-6587.

Best regards Mathias.

janmattfeld commented 3 years ago

Whenever backend processing takes magnitudes more time than transmission, I often found it helpful to just disable pagination during backend processing and send back complete datasets. sap.ui.table.Table then allows smooth scrolling without further busy indicators (SAPUI5 1.71.29).

However, a better handling of the table's threshold value would still be very much appreciated.

uhlmannm commented 3 years ago

@janmattfeld, when looking closer it turns out that there was a change on 02.03.2020: https://github.com/SAP/openui5/commit/ae24c6c8bbf465ca5fd577474e6d07040bbd7b7e#diff-5add548eebd18494137809c6aff34bcd8c1e32d95b689c434ed28261063a59f2. That is included in 1.71 and since 1.76.

With that change it is at least ensured that every time a request is triggered at least threshold records are fetched. In your example, this would not avoid the request with the first scrolling. However, later requests would be avoided.

  1. GET Orders?$skip=0&$top=505
  2. GET Orders?$skip=505&$top=500
  3. No request when going, e.g., to position 450.

Does that help already?

Best regards Mathias.

pksinsik commented 3 years ago

Hi @janmattfeld,

with commit 959d94f we have improved the gap calculation which runs on pagination: We now have a central, reusable logic which optimizes the requests when scrolling in a table.

Note:

  1. There are still cases where the table goes busy when only prefetching data, i.e. visible row data is already available and only data from the threshold range is being loaded. We have the already mentioned FIORITECHP1-6587 to work on this, so I will keep this issue open.
  2. The effect to see more than one request for table data may still occur in case of server-driven paging (see e.g. https://www.odata.org/documentation/odata-version-2-0/json-format/, section 6, __nextLink) if you choose a threshold which is nearby or larger than the server page size (200 for the Northwind). For this case one should either enlarge the server-page size (if possible) or adapt the threshold if this is not possible to avoid mulitple sequential data requests.

Best regards, Patric

janmattfeld commented 3 years ago

@uhlmannm Thanks, I checked the behavior and it's an improvement for sure.

@pksinsik That sounds really helpful! Will the change also be included in 1.71?

Thanks, Jan

pksinsik commented 3 years ago

Hi @janmattfeld,

we won't do a downport to 1.71 due to the dependencies of the mentioned commit and the resulting effort. Moreover, with commit d8132db we already downported an improvement which avoids requests each time you scroll.

Best regards, Patric

pksinsik commented 2 years ago

While there is still some improvement pending for the mentioned FIORITECHP1-6587, which is to fix edge cases where the busy indicator is not displayed reliably, the original issue described here is solved.

MrVila commented 2 years ago

Hi,

We are facing same/similar issue using version 1.84.25.

I can put a threshold of 5k. After the first load (5k items), when I scroll a bit down (just to see the first 50 results), is loading the next 5k results. This is really annoying.

I wonder in which version is this fix, or if I need to open a new issue. Maybe you are already working in FIORITECHP1-6587, but I don't know to check it.

Best regards, Jordi

uhlmannm commented 2 years ago

Hi Jordi (@MrVila ),

with commit 959d94f we have improved the gap calculation which runs on pagination: We now have a central, reusable logic which optimizes the requests when scrolling in a table.

The commit mentioned by Patric is part of 1.93.

Best regards Mathias.