Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Reset filters to default when switching tabs #2056

Closed

Conversation

frankli-dev
Copy link
Contributor

Issue:
See recording
https://github.com/paritytech/polkadot-staking-dashboard/assets/51565705/0a04f1e7-2668-476c-8208-c72392f6efa9

After fix:
https://github.com/paritytech/polkadot-staking-dashboard/assets/51565705/1b72d2d5-01a6-470f-bf89-77dad5b2e5bb

When switching tabs, it doesn't reset the filters (search text & selected subtab).

There can be two ways to fix this.

  • Introduce a new state to save the selected subtab
  • Reset filters to default when switching tabs or landing on pools tab

This PR handles in the second way.
Happy to contribute!

@rossbulat
Copy link
Collaborator

Thanks for identifying the issue @frankli-dev.

I am currently working on an optimisation to only fetch pool performance data one page at a time as and when the user visits All Pools. If we go ahead with clearing the list state on tab change, I have noticed that this performance data would need to be re-fetched every time the user switches back to the list tab if the list has been altered in any way from its default. To prevent more expensive fetching of performance data, perhaps it is more optimal to just have pool context state items to globally save the search term and active tab. Then there will be no need to re-fetch performance data again on tab switching.

The above issue does not exist currently as the app is fetching performance data for every pool on app initialisation - super resource intensive and slow process.

The latest code has a one-click pool joining process from the Pools page directly. I don't think All Pools will be visited as much once this is live. This is partly why I've opted to do per-page performance fetching instead of the whole lot on app load. With 224 pools now, this will soon not be scalable.

Please allow me to finish my optimisation PR (no need to continue working on this one). The videos and diagnosis of the issue have been very helpful, thank you again.

@frankli-dev
Copy link
Contributor Author

Awesome! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants