I choose store solution rather than project the current state to url.
It resolved the annoying UX, but it's nothing advanced. As you see in the demo, the tx data is a snapshot from the initial access to the page. EG: You go 3 pages Next, you go 3 pages back (even tho there has been new transactions created).
Some advanced solution would require page index information from MDW. Currently, we count the page index on FE. So for the case going back from detail to listing, the app will lose information about the current page index.
I don't think such a solution is good.
I also recommend checking reference explorers, how they solve it. They have more simplistic solution
github-actions[bot]
commented
3 months ago
Description
resolves #462
I choose store solution rather than project the current state to url.
It resolved the annoying UX, but it's nothing advanced. As you see in the demo, the tx data is a snapshot from the initial access to the page. EG: You go 3 pages Next, you go 3 pages back (even tho there has been new transactions created).
Some advanced solution would require page index information from MDW. Currently, we count the page index on FE. So for the case going back from detail to listing, the app will lose information about the current page index. I don't think such a solution is good.
I also recommend checking reference explorers, how they solve it. They have more simplistic solution
Demo
https://github.com/aeternity/aescan/assets/15363559/a78703b6-8204-4dd5-8150-4973bb8ccbe7
Checklist: