-
Notifications
You must be signed in to change notification settings - Fork 521
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
Implement Pagination for API Keys Table #2540
Comments
/assign |
This issue is not part of oss.gg hackathon. Please pick a different one or start with a side quest |
This entire page needs to be redesigned, we're currently planning this. |
/award 50 |
Awarding unrenamed: 50 points 🕹️ Well done! Check out your new contribution on oss.gg/unrenamed |
@chronark should i add pagination to this? |
@chronark can I work on this issue if no one is working on it? |
@chronark can i go with this?? |
Preliminary Checks
I have reviewed https://unkey.com/docs for existing features that would solve my problem
I have searched for existing feature requests: https://github.com/unkeyed/unkey/issues
This issue is not a question, general help request, or anything other than a feature request directly related to Unkey. Please ask questions in our Discord community: https://unkey.com/discord.
Is your feature request related to a problem? Please describe.
Yes, the feature request is related to a significant usability problem. Currently, the API Keys table displays only the first page of results, limiting users' ability to access or view the remaining 400 keys from a sample of 500. This can lead to frustration and inefficiencies when users need to manage, review, or analyze a larger set of keys, as they cannot navigate beyond the initial page.
Describe the solution
The proposed solution is to implement a pagination feature for the API Keys table. This would involve one of the following approaches:
Adding controls (such as "Previous," "Next," and page numbers) to navigate through the different pages of keys.
Allowing the table to load a specific number of keys per page (e.g., 10, 20, or 50), providing a manageable view of the data. Given the existing
cursor
-based pagination in the API, this may be the most optimal approach.Describe alternatives you have considered (if any)
Alternatives considered include:
Additional context
Screen.Recording.2024-10-22.at.21.54.31.mov
The text was updated successfully, but these errors were encountered: