-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Pagination on Usage page #12501
Pagination on Usage page #12501
Conversation
started the job as gitpod-build-alex-slowness-loading-usage-list-12388.1 because the annotations in the pull request description changed |
started the job as gitpod-build-alex-slowness-loading-usage-list-12388.2 because the annotations in the pull request description changed |
0f1c12b
to
be92c4f
Compare
/hold
|
be92c4f
to
f87e6b6
Compare
/hold cancel |
Hey Alex! I can look into this. Do you have a team set up (invite link?) that has a bit of usage shown already? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to your previous PR, this PR would greatly benefit from being split into multiple. The following steps lean themselves very nicely.
- Change proto
- Implement the UsageService logic, defaulting to Page Size of "Everything" to maintain current behaviour when the number of results is not specified
- Change Server/dashboard to specify number of results per page, and paginate
As it stands, the big PR causes any changes to the underlying API protocol to force you to change everything else. It's better to agree and commit to the API spec and only then progress with the changes.
The current version (all in one) also suffers from undefined behaviour as the changes rollout across dashboard/server/usage. We do not know if the UI will handle only one page of changes properly if it doesn't yet know about the request per page logic.
@easyCZ, thanks for the comment. I think we know about the impact pretty well. Considering the timeline, I'd prefer to solve this as a vertical.
In theory this is great, I'm kind of skeptical this works out nicely in a three layered cake. Once you meet the needy requirements from implementing the dashboard, you'll likely start out with the next iteration. Let's move general discussions out of PRs, please! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks super good 🧡 Just a few smaller things.
}; | ||
const prevPage = () => { | ||
if (currentPage !== 1) setCurrentPage(currentPage - 1); | ||
if (currentPage !== 1) setPage(currentPage - 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not directly related to this PR #12537
/hold
|
@svenefftinge the navigation between months is fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thank you for this @AlexTugarev
/hold because of test commit
b9c025a
to
0960113
Compare
/hold cancel |
Description
Adding server-side pagination to list usage.
❗ There is a test commit to set the
perPage
attribute to a value of3
, which makes this PR handy to test. That should be removed before merging.Notes
Timestamp
is removed as agreed-on[ 1 ]
page links to make them clickableRelated Issue(s)
Fixes #12388
How to test
Release Notes
Documentation
Werft options: