Add Pagination to Downloads/Publishes/Wallet pages #626

New issue

Closed

opened 2017-09-26 15:26:30 +02:00 by lyoshenka · 8 comments

lyoshenka commented

2017-09-26 15:26:30 +02:00

(Migrated from github.com)

@tzarebczan commented on Mon Aug 28 2017

The Issue

As LBRY usage grows, users will accumulate many items in Downloads, Publishes and in their wallet. The app should have the ability to paginate on these screens. This should also make the user experience more pleasant as less data needs to be loaded on each refresh. Sorting/filtering options would be nice in all the areas as well.

Expected behaviour

Paginate through LBRY areas

Actual behaviour

Each page loads all data

System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

@tzarebczan commented on [Mon Aug 28 2017](https://github.com/lbryio/lbry/issues/876)  ## The Issue As LBRY usage grows, users will accumulate many items in Downloads, Publishes and in their wallet. The app should have the ability to paginate on these screens. This should also make the user experience more pleasant as less data needs to be loaded on each refresh. Sorting/filtering options would be nice in all the areas as well. ### Expected behaviour Paginate through LBRY areas ### Actual behaviour Each page loads all data ## System Configuration   - LBRY Daemon version: - LBRY App version: - LBRY Installation ID: - Operating system: ## Anything Else  ## Screenshots

alyssaoc commented

2018-08-28 19:30:55 +02:00

(Migrated from github.com)

@tzarebczan open lbry side issues as appropriate

tzarebczan commented

2019-02-02 00:07:39 +01:00

(Migrated from github.com)

transaction list and claim list mine both have pagination options - we should implement these on the app side. Currently we are running into performance and lockup issues with larger wallets (i.e. youtubers with lots of videos). File_list is not yet implemented (https://github.com/lbryio/lbry/issues/1650)

kauffj commented

2019-02-04 16:17:39 +01:00

(Migrated from github.com)

I'm not looking for immediate action here, but @tzarebczan @lbryio/protocools please keep an eye on these issues and file performance issues against lbry as well. I do not see why we can't return thousands of records in a performant manner.

I support pagination from a UX perspective (super-long lists are hard to use), but the fact that performance is a driver here is somewhat concerning. Given that everything is coming from a local database and the overall data is a reasonable size, what is the performance bottleneck? I'm not looking for immediate action here, but @tzarebczan @lbryio/protocools please keep an eye on these issues and file performance issues against `lbry` as well. I do not see why we can't return thousands of records in a performant manner.

neb-b commented

2019-02-04 16:37:40 +01:00

(Migrated from github.com)

This is not related to the daemon, but rather trying to render 1000s of items on the screen at the same time (even if they are off the screen). React does try to batch some of the updates, but if you have a large amount of files, the page is going to update a lot. I just went to my downloads page and with 347 downloads the page re-rendered 339 times as it was getting data.

It's probably worth looking at seeing how much we can improve performance before paginating (lazy load, virtual lists, batching updates better).

kauffj commented

2019-02-04 16:53:50 +01:00

(Migrated from github.com)

Got it, thank you. Still somewhat concerning though not necessary to address immediately. I will say that anytime we have performance rather than UX as a design driver, we should take it as a cue to step back and do some research/learning to see if we're doing something that is more fundamentally mistaken.

kauffj commented

2019-07-08 21:23:20 +02:00

(Migrated from github.com)

(this issue is blocking wallet transfers)

kauffj commented

2019-09-18 19:09:55 +02:00

(Migrated from github.com)

@tzarebczan to share wallet that reproduces issues

jessopb commented

2019-09-19 02:22:26 +02:00

(Migrated from github.com)

I looked first at paginating transaction list. Being able to go to #/$/transactions?page=2 isn't very meaningful when the filter options could be set to anything.
Desired behavior with navigating to #/$/transactions?type=all&page=2 should be that it both sets the filter type in the component and updates redux filter type. When onChangeFilter happens, we update the redux filterSetting state as usual, and the history.push url will add &type=filterSetting.

I looked first at paginating transaction list. Being able to go to #/$/transactions?page=2 isn't very meaningful when the filter options could be set to anything. Desired behavior with navigating to #/$/transactions?type=all&page=2 should be that it both sets the filter type in the component and updates redux filter type. When onChangeFilter happens, we update the redux filterSetting state as usual, and the history.push url will add &type=filterSetting.