In order to be able to implement some transaction list improvements (e.g. filter out Ehtereum scam transactions or #7005), we have to decouple transaction pagination in Suite UI from api call pagination. The steps should be approximately following:
remove pagination in TransactionList and make it infinitely scrolling list instead (with some clever UI maybe?)
fetch new transaction batch when needed
component virtualization/recyclation must be resolved first as the list can be quite long
page concept (page param in fetchTransactionsThunks) can be still preserved under the hood, but only directly following pages will be ever accessed
must work with tx filtering
load all the account transactions eagerly instead of on demand
good for local-first, offline mode etc.
the same thing happens when filtering or exporting transactions
it can happen right after discovery (#7003), but it definitely shouldn't slow it down, so think about it as a second non-blocking stage of discovery?
With this, it should be possible to hide some transactions as they wouldn't need to correspond to selected page, and we won't have to deal with expected undefined's in transactionReducer arrays because no page will ever be skipped.
In order to be able to implement some transaction list improvements (e.g. filter out Ehtereum scam transactions or #7005), we have to decouple transaction pagination in Suite UI from api call pagination. The steps should be approximately following:
TransactionList
and make it infinitely scrolling list instead (with some clever UI maybe?)page
param infetchTransactionsThunks
) can be still preserved under the hood, but only directly following pages will be ever accessedWith this, it should be possible to hide some transactions as they wouldn't need to correspond to selected page, and we won't have to deal with expected
undefined
's intransactionReducer
arrays because no page will ever be skipped.