Feature Request: pagination instead of lazy load scroll

[JesusTheHun]

On a wallet page, the list of the most recent transactions is displayed. Going at the bottom, you can hit the "more" button, to add previous transactions to the list. This system is nice for short lists, when you don't necessarily need to browse the list. However, for a blockchain transaction list, it is unappropriate, for several reasons :

• I cannot go to the last page, to see the first transactions
• I cannot share to a friend a group of transaction by telling the page number
• I cannot bookmark a specific range of transactions
• If I load more and more and more transactions, it becomes a memory issue on smallest mobile device
• Still on mobile device I have to do an endless finger scroll to go back to the top after loading more transactions

Please replace this system with an old fashion pagination.

[MichalTuleja]

The current implementation requires accessing more data by clicking more multiple time.
The planned pagination improvement concerns the following views:

• Blocks view
• Planned generic transaction view Add generic transaction page #813
• Account: Transaction view
• Top Accounts

[lsilvs]

Lisk Core API does not return the total amount of items for /blocks and /accounts endpoints as it does for /transactions endpoint. The lack of total amount of items make it impracticable to implement a proper pagination with the number of pages and link to the last page for example.
A work around for blocks would be using the current block height as the total amount of blocks.
I can't think of a work around for accounts though.

[lsilvs]

Closed by mistake...

[JesusTheHun]

For blocks, indeed you can use this method. It's simple and efficient.

For the top accounts, the total number will be the total number of Lisk addresses.

I don't know how it's done internally since the public API does not provide such ranking system, but seeing the http request I would say a) you hit the blockchain database directly or b) it's a fetch of a cached sorted list. If it's cached it's length-fixed. Eitheir way you can count the number of items.

But ironically, this kind of page is ok to have a lazy load, since the position of each account is likely to move. It's almost always better to have a pagination, but for this very specific page, it's ok.

[MichalTuleja]

@lsilvs I agree, block height should be enough.
Assuming that the number of accounts is difficult to get without significant changes to the backend is not worth doing that now. I would suggest leaving Top Accounts as it is and change it once the new API is ready.

[MichalTuleja]

Further development will be continued in the #850 #851.