feat: implement reverse paging

[travis]

Use the new pre caveat and before and after cursors from storacha/w3infra#139 to implement reverse paging

reverse.paging.mov

[olizilla]

The aws s3 ui fake pagination is a good example here. It shows large pages of ~300 items, so new users don't have to think about paging at all, and in practice it loads 900 items immediately, and then shows the user 1, 2, 3 ... >.

Clicking between 1,2,3 loads that "page" from local state. Clicking on the arrow fetches the next 900, divided over another 3 pages, showing 1, 2, 3, 4, 5, 6 ... >. You can click any number and jump to that page, without a network request. If you click the arrow again, you get the next batch and now it shows < 1, 2, 3, 4, 5, 6, 7 ... 10 >, and you can page forward and backwards through them...

I think we should keep enough state locally to implement something similar in the UI.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1f928a4:

Sandbox	Source
@w3ui/example-react-file-upload	Configuration
@w3ui/example-react-sign-up-in	Configuration
@w3ui/example-react-uploads-list	Configuration
@w3ui/example-solid-file-upload	Configuration
@w3ui/example-solid-sign-up-in	Configuration
@w3ui/example-solid-uploads-list	Configuration
@w3ui/example-vue-file-upload	Configuration
@w3ui/example-vue-sign-up-in	Configuration
@w3ui/example-vue-uploads-list	Configuration

[travis]

I think we should keep enough state locally to implement something similar in the UI.

I like this, will take a crack at it tomorrow!

[travis]

this PR should be testable by others now - the upload-api changes it depends on are now in production

[travis]

The aws s3 ui fake pagination is a good example here. It shows large pages of ~300 items, so new users don't have to think about paging at all, and in practice it loads 900 items immediately, and then shows the user 1, 2, 3 ... >.

Clicking between 1,2,3 loads that "page" from local state. Clicking on the arrow fetches the next 900, divided over another 3 pages, showing 1, 2, 3, 4, 5, 6 ... >. You can click any number and jump to that page, without a network request. If you click the arrow again, you get the next batch and now it shows < 1, 2, 3, 4, 5, 6, 7 ... 10 >, and you can page forward and backwards through them...

I think we should keep enough state locally to implement something similar in the UI.

OK so - this is definitely doable, but will take a bit of work because we currently store state all the way up in the UploadsListProvider. I have already had an itch to redesign how state management here works, because in the current implementation we have to set page size in the Provider, which feels awkward given that most of our providers are configured at an app level.

I think that generally we should separate uploads list state from the code that provides uploads list API functions so that the API can be added at the app level and individual upload list state can be provided closer to where the uploads list is rendered. This will also be a good opportunity to ensure we can implement the "fake paging" pattern you describe here more easily.

I'd like to move this redesign to a separate task if you don't mind, so that it can be prioritized and implemented separately - what we have here is already an improvement and should work pretty well for most users today, and I'd like to move on to other tasks for now - happy to file an issue to make sure we don't lose track of it - @olizilla what do you think?

[alanshaw]

LGTM, please fix the CI