DPL-659 - Bioscan - Add paging to samples list in labware summary screen to cope with 9216 samples

[andrewsparkes]

User story As PSD we need to add paging to the sample listing to cope better with the 9216 samples.

Who are the primary contacts for this story PSD

Who is the nominated tester for UAT PSD

Acceptance criteria To be considered successful the solution must allow:

• [ ] labware summary screen samples listing has paging for a labware (tube) with over 384 samples

Dependencies This story is blocked by the following dependencies: None

References This story has a non-blocking relationship with: None

Additional context Consider 384 samples per page so it still only needs one page for most labwares. Consider if there are other relevant listings that need paging e.g. library requests. Could also default the list to being 'collapsed'.

[TWJW-SANGER]

I would consider what users are going to do with this page. I think it is unlikely anyone would click through all the pages required to show 9216 samples (even at 384 samples a page...). For instance - would limiting the displayed list and giving the option to download the complete sample lists be more useful? Or perhaps searching/filtering within the sample set is more useful than pagination?

I can see the default page behaviour needs to change in order to cope, but are there other solutions to consider apart from pagination ?

[yoldas]

There are two approaches to pagination:

1. Do the paging on the server and render the page (We are doing this)
2. Send all data to client and let the client render pages
3. Send data to client as necessary.

We are not implementing the second approach, because it will still cause too much data to be sent to the client.

We are implementing the first approach. Samples list will be divided into 384 rows. We will add a pagination (page numbers) display before and after the listing. Collapse button will be available to show/hide the samples listing to reach the other content below the listing easily.

The search button will search the data within the current page (Changing it to search all data and re-rendering the listing could be another story - Related to 3rd approach). The sorting using column headers work for the current page.

We are listing the samples in the following places as a long list:

Labware samples: Route: /labware/:id Files: app/controllers/labware_controller.rb app/views/labware/show.html.erb app/views/assets/samples_partials/_asset_samples.erb spec/views/labware/show_html_erb_spec.rb

Receptacle samples: Route: /receptacles/:id Files: app/controllers/receptacles_controller.rb app/views/receptacles/show.html.erb app/views/receptacles/_samples.erb (Test missing)

Study samples: Route: /studies/:id/samples Files: app/controllers/studies/samples_controller.rb app/views/studies/samples/index.html.erb test/controllers/studies_sample_controller_test.rb (No partial for this one)

Questions: Should we rename @aliquots variable to @aliquots_paged Do we still need to pass @asset in the partial Do we break anything else if you don't pass @asset Did we break tube racks? What is the default sort order for building the pages?

[yoldas]

Pagination on receptacles seems to be breaking NPG Aliquot Index