Infinite scroll of large query in orders cannot display all search results

Description

This applies to our local tamu instance, release 3.2.

There are between 17K and 18K purchase orders loaded in this instance. When you go into the orders app and execute a search that returns a large result, then scroll down, you begin to see blank lines in the display within a screen or so. See attachment for an example screenshot. The screen in question eventually displayed the next set of rows to fill out that screen but it took 26 seconds.

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

2
  • 29 Nov 2019, 11:11 AM
  • 15 Oct 2019, 09:27 PM

Checklist

hide

TestRail: Results

Activity

Show:

Khalilah Gambrell February 24, 2020 at 1:25 PM
Edited

and , please see the stripes-updates posts https://folio-project.slack.com/archives/CR3FJRSAD/p1576618721001400 and https://folio-project.slack.com/archives/CR3FJRSAD/p1576618721001400. You can apply the load more button to Orders to address this UX issue.

cc: , ,

Ryan Berger December 2, 2019 at 2:45 PM

Re: . We closed STCOM-622 during a sprint review but didn't update with a comment. I have done that now to indicate that we are moving forward with the "load more" button. Thanks for keeping us accountable! slightly smiling face

Dennis Bridges November 29, 2019 at 6:11 PM

I'm closing this issues as won't do because work will continue in STRIPES-663 and STCON-57 toward a global solution that will ultimately be leveraged by Acquisitions and the Orders app.

Zak Burke November 29, 2019 at 12:12 PM

This is a known issue and a big part of what led us down the road to filing STRIPES-663 regarding a stripes-connect replacement. See also STCON-57, derived from CHAL-91, which describes the same problem. As noted in Slack after the related #stripes-architecture discussion:

• CHAL-91 (Infinite scroll breaks/freezes when you scroll using scroll bar) opens a can of worms WRT stripes-connect. The smallest/fastest fix would be to add a “load more” button to the bottom of the list, effectively changing from automatic to manual infinite scroll.

• Addressing CHAL-91 in almost any other manner would involve some major surgery on stripes-connect. The general feeling was that while stripes-connect has been a workhorse for us, we have never been able to dedicate the resources necessary to make it a fully-fledged library. There was nothing like it when Jason at the time it was created, but the landscape is different now: there is GraphQL of course, and many other REST-oriented libraries. We MUST take a real look at those alternatives, or dedicate real resources to updating stripes-connect. Filed the SPIKE STRIPES-663 with the intent to do some research over the next few months and form a plan at the start of next quarter.

We were working on this under STCOM-622 and I thought were headed toward the "load more" button but I don't know what the final conclusion was. can you provide an update on STCOM-622 about why it was closed? There are no comments there explaining why it was closed, or the current direction of this work.

Aliaksei Chumakou November 29, 2019 at 11:13 AM

At least for users I can see the same. Infinite scroll feature repeats query for every portion on scroll down, not only for the new one. Again, as for me I'm not sure if we should change this right now - people might want to use filter and search rather than scrolling down. And this issue became unresponsive for like thousands of records.

Won't Do

Details

Assignee

Reporter

Tester Assignee

Priority

Story Points

Sprint

Development Team

Thunderjet

Fix versions

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created October 15, 2019 at 9:28 PM
Updated February 24, 2020 at 1:44 PM
Resolved November 29, 2019 at 6:11 PM
TestRail: Cases
TestRail: Runs

Flag notifications