feat: cache wallet page transactions #1269
This PR introduces a simplistic, but effective, way to cache transactions (resolves #894).
What kind of change does this PR introduce?
Does this PR introduce a breaking change?
Does this PR release a new version?
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
If adding a new feature, the PR's description includes:
requested review from
May 30, 2019
@@ Coverage Diff @@ ## develop #1269 +/- ## ========================================== + Coverage 39.88% 39.9% +0.01% ========================================== Files 229 229 Lines 6345 6367 +22 Branches 1253 1253 ========================================== + Hits 2531 2541 +10 - Misses 3592 3601 +9 - Partials 222 225 +3
luciorubeens left a comment
I'm randomly getting the new transactions banner:
uhmm, @luciorubeens could you try to capture under which circumstances do you see that banner? I've never see it (it works well when I sen a transfer).
About storing only the last transactions and only store wallets / contacts, my idea was making navigation smoother, so users don't have to wait to navigate to / from pages that have been already visited. That specially useful under bad network conditions due user connection or due using a slow peer.
About the expiration date, what do you propose? flushing those old transactions at the beginning? checking the date every time that they are accessed?
IMO you should cache all txs under one
And btw ordering of txs just doesn't work.
IMO you should only order the txs on the current page on the fly, same way the explorer is ordering them, without calling the API.
Thanks, @zillionn. I'll fix the ordering on this PR.
About sorting the transactions of the current page only, we can't do it because we'd lose a lot of functionality: for instance, users would need to navigate between lots of pages to see the first one, instead of just ordering them ascendantely. In the explorer that use cases are not as important.
And about aggregating transactions by address (instead of using the address, but the pagination too) the problems with that approach are:
Keep in mind that this PR focus on making the navigation faster, not on having a copy of the entire data of an address. That could be a waste of space in several scenarios.
I'll just say that you don't have to download all the txs, you only download/cache the last 50 (limit per page) txs. If you change the order, you update the cache with the new 50 txs. But most importantly, when I hit
Caching the last 50 would cover only 5 pages, so it could be useful, but it's limited.
About the refresh button, using the search endpoint to fetch only the latest could be a good optimization in some cases. Probably we could keep this PR approach and, later, dig into that other kind of enhancements.