Update frontend to use pagination from the apis

[joshJarr]

BLOCKED until api is completed via #1507 and #1362

Tasks

• [ ] adjust accounts page in website to use the updated uploads api and pinning api to retrieve needed data for page.
• [ ] implement pagination for the accounts page list of user uploads
• [x] eliminate the "sort by size" from the list of UI options to sort files (since that will not be supported by updated pagnated api.
• [x] Disable the file search bar feature, since no way currently to search with new pagination ( this ticket was removed from scope #1509). This feature will return with new uploads v2.
• [x] Highlight that search is deactivated, but being upgraded. Possibly fade out the bar visually to indicate deactivation. also need to put some message there about "Upgrade to search underway" perhaps in the placeholder copy, maybe also with construction icons.

Rough mock showing the bar with updated placeholder copy

Original Spec (some elements may be inaccurate, like size sorting)

With this PR: https://github.com/web3-storage/web3.storage/pull/1408 pagination is added to the GET /user/uploads endpoint. Using additional size and page params, uploads can be fetched in batches with the pagination metadata being returned by the response header.

The frontend should use these new parameters to batch user uploads into pages to improve the efficiency of calls for users with a large number of files.

[joshJarr]

Hi! I started looking into this but realised when implementing it was a bigger task that conflicted a bit with the pinning table work. Here's my WIP branch anyway encase it helps!

My approach was to attempt to not rely on the lower level UI components such as the sorting Sortable, the size selection Dropdown and Pagination to manipulate data, but instead reflect their changes in the URL query params, and extending the watcher for these query params to refetch the data on change passing the URL query params as arguments.

A few gotchas I found:

• To display the number of pages for the pagination component I've returned more pagination metadata in the response header. I did this as I didn't want to introduce a breaking change into the API, but if it is better to include in in the response body I can do so!
• I found it tricky when trying to merge what I have done with the new pin table work, which is my bad for not keeping an eye on the horizon of other initiatives, but realised we don't have pagination on the pinning GET /pins endpoint, so the common components were being used in different ways - I'll make a ticket to replicate the API pagination in GET /user/uploads into the GET /pins endpoints to help this!
• Testing this was tricky, I made a script to generate 1000 uploads, I'll make a ticket for this so I can clean it up and commit it. I could also add pin generating to this.
• A few instances of useEffect is used to watch param and variable changes, and I found this duplicated some function and API calls.

Missing functionality: We don't yet have parity between FE and BE sorting.

• Sort by file size is currently not achievable by the API, ticket 1508 has been created to track this.
• Searching all uploads is also not possible in the API, captured in ticket 1509

[drewdelano]

@JeffLowe mentioned this work was being moved over to Potato

[dchoi27]

@mbommerez what's the latest on this?

[mbommerez]

@dchoi27 this is not scheduled. @joshJarr worked on the backend but is on holidays this week and scheduled to work on w3name next week. Should we re-prioritise? Thanks!

[dchoi27]

Oh I thought w3name was pretty much wrapping up this week. Would be helpful to understand how much work is left for w3name (that Josh would be working on) vs. this issue!

[dchoi27]

bumping @mbommerez otherwise let's have @JeffLowe and team work on it. would be good to get this in as soon as possible!