CRDCDH-1608 Create column filtering for tables and add filters to Data Submission List table

[Alejandro-Vega]

Overview

Added ability to toggle column visibility on Data Submission List table. Also added additional filters to narrow down search.

Change Details (Specifics)

• Added column visibility button and popper to make it easily reusable
• Added show all and reset buttons for the column visibility popper
• Created hook to manage column visibility and to handle the logic of hideable columns as well as managing local storage.
• Separated filter logic out of the Data Submission list view component and added new filters for Data Commons, Submission Name, dbGaP ID, and Submitters
• Retrieved list of Data Commons and submitters from API to populate dropdowns
• Added debounce to text inputs after 3 characters are typed and delay is 0.5s. (Ticket says 0.1s, but I increased it to match other debounce fields, I left comment in ticket)
• Added reset button which resets the state of all filters and removes the search params from the URL, but still keeps the search params for the table state (ex. page number, rows per page, etc.)
• Maintain filter state in the URL where it will persists between refreshes. It will also be restored if you click into a data submission and click back
• Fixed bug with Manage users and Manage orgs list tables. If you navigated to a page other than 1, then changed the filters, it would show a weird table which is due to the page number not properly resetting on filter change
• Fixed bug with Manage orgs table where it was missing a dep for the "study" filter which caused it not always to apply the filter to the table. I added the missing dependency to fix the issue
• Update default rows per page of table to 20
• A side-effect of filtering by Submitters and having those submitterNames being filtered by the other filters, is that if another filter changes then the name may no longer be a valid name. This will cause the Submitter dropdown reset back to "All". In order to check if the name is valid with the new filters, it makes 2 API calls instead of just the 1.

Note

Sorting for list of Data Commons and Submitters will be done on the BE.

Related Ticket(s)

CRDCDH-1608 (Task)
CRDCDH-1586 (User Story)

[amattu2]

@amattu2 If you have time, can you check to see if maybe your tests are being a bit laggy by re-running them, or if the site is a big laggy. It could just be my device, but I can't tell. I checked for memory leaks on the browser and it seems fine. The test heap sizes are pretty big for quite a few of them, but unsure if related. If it all seems good on your side, then disregard this.

It looks like the run time for Jest in CI has jumped ~10s in this PR. If you added a lot of tests that use async with waitFor then this is probably to be expected, especially since I limited the number of tests that can run in parallel (#454). Locally, however, the run time has only increased like 1 second at most (approx. 35s total).

Last 3.1.0 run

Last run in this branch

Anecdotally, Jest has always randomly bogged down for me locally, but it disappears usually after rebooting.

[amattu2]

A few questions and suggestions are annotated below. In general, most of them are optional.

[amattu2]

As a side note, not directly related to this PR, the GenericTable does a lot of rerendering during the initial display of rows and subsequently causes all of the nested components to rerender with it. At some point, we should attempt to stabilize it more with stronger memoization for props/etc.

Just a potential QoL improvement for the future (maybe 3.2.0).

[Alejandro-Vega]

As a side note, not directly related to this PR, the GenericTable does a lot of rerendering during the initial display of rows and subsequently causes all of the nested components to rerender with it. At some point, we should attempt to stabilize it more with stronger memoization for props/etc.

Just a potential QoL improvement for the future (maybe 3.2.0).

Agreed, unfortunately I let it get out of hand. The table is becoming quite a mess. It is in need of some strong refactoring, but will be quite the lift. Fixing the re-rendering problem is definitely a good start.

[amattu2]

LGTM.

[amattu2]

Skipping updating the branch, only minor changes in 3.1.0.