Skip to content

Add pagination or infinite scroll support #11483

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

Closed
gtsiolis opened this issue Jul 19, 2022 · 5 comments · Fixed by #11481
Closed

Add pagination or infinite scroll support #11483

gtsiolis opened this issue Jul 19, 2022 · 5 comments · Fixed by #11481
Labels
component: dashboard team: webapp Issue belongs to the WebApp team type: feature request New feature or request

Comments

@gtsiolis
Copy link
Contributor

gtsiolis commented Jul 19, 2022

Problem to solve

Pagination. 📄

Proposal

🅰️ Pagination breaks up content into multiple pages.
🅱️ Infinite scroll helps users parse a large number of items. Infinite scroll is also suitable when the list updates frequently and there are no sorting or filtering options.

Cc @laushinka @jldec because of our recent discussion related to pagination.

Designs

Pagination (Simple) Pagination (Complex)
Simple Complex
Infinite Scroll (Simple) Infinite Scroll (Loading) Infinite Scroll (Showing All)
InfiniteScrollSimple InfiniteScrollPage InfiniteScrollAll

See design specs.

@gtsiolis gtsiolis added type: feature request New feature or request component: dashboard team: webapp Issue belongs to the WebApp team labels Jul 19, 2022
@laushinka
Copy link
Contributor

Thanks for the designs!
@gtsiolis @jldec If paginated, how many results do we want to show per page?

@gtsiolis
Copy link
Contributor Author

@laushinka, 20 is usually a good starting point for pagination that makes sense, but also depends on the context.

However, I'd say let's go with 10, which is also a common approach, for brevity following our approach with other product areas like the workspaces list (see inactive workspaces grouping, etc) and given the upcoming collapsible component to be added on each entry and the potential addition of the usage graph above this list (see relevant discussion (internal)).

We can always adjust this in future iterations. ➿

Looping in @jldec in case he has any strong preference towards a different solution. 🏀

@laushinka
Copy link
Contributor

20 is usually a good starting point...
let's go with 10, ... and given the upcoming collapsible component to be added on each entry and the potential addition of the usage graph
We can always adjust this in future iterations. ➿

Agree! I also thought 10 is a good start. For now we're doing the pagination in the client instead of the server, so once the data is loaded, going through the pages takes no time at all.

@gtsiolis
Copy link
Contributor Author

For now we're doing the pagination in the client instead of the server, so once the data is loaded, going through the pages takes no time at all.

I assume in the long-run we will switch to server-side pagination. Until then in case we notice any significant loading times, we could drop in a loading spinner while loading the data. ⏱️

@laushinka
Copy link
Contributor

I assume in the long-run we will switch to server-side pagination.

Exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: dashboard team: webapp Issue belongs to the WebApp team type: feature request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants