Open samiyaakhtar opened 4 years ago
- [ ] Think about whether data should be fetched when the user tries to view the next page, or lazy loading
@samiyaakhtar maybe we can start with this first and break out a spike task since this is XL effort
@andrebriggs opened task https://github.com/microsoft/bedrock/issues/874
Context Azure builds expire after 2 weeks SPK shows builds of the last 2 weeks Azure Storage API: returns a max of 1000 items at once, may execute for a max of 5 seconds
Objectives Rendering long lists freezes the UI Improve readability/usability Infinite scrolling, lazy loading table
Approaches
Client-Side Pagination
Load all deployments in the background as the page loads but displaying them in multiple pages. This helps the filters work across all the deployments since filtering can be client-side.
Pros:
Leverage existing front-end sorting and other existing front-end logic
Fast load time between pages
Fast filtering
Cons:
It will not scale with significantly more data because it will have to be fetched all at once.
Azure-Storage Pagination API Load deployments by page (get azure table results by page) and filtering should fetch results from server-side Pros: Leverage the Azure Storage pagination API Data is not fetched all at once Cons: Azure Storage Table doesn't support order by for sorting New custom logic to sort/filter across the data and fetch the given page Network requests upon navigating between pages Estimated longer time to implement compared to the client-side approach
Conclusion Client-side pagination is sufficient for the SPK use case given the context and objectives listed above.
UI should indicate that there are several pages available to view
@samiyaakhtar given the idea of "infinity scrolling" is this still accurate?
One idea is that we limit data to N rows then we provide a search functionality for anything more than that. This way we can create a different operation for queries that users have. This will be much simpler than attempting to manage pages or infinite scrolling. cc @jred55 @gemorris @samiyaakhtar
Another strategy could be implementing a "default filter" e.g. when the page loads it is by default filtered to the last N days, and the user could then choose to remove that filter (and have a slower load time)
After discussion in the weekly meeting I think the best strategy is to by default load N rows (likely 50) and then below the last row, add an additional row with different styling that says "Currently only viewing the first N rows, click here to load all rows"
As a: developer/manager/operator
I want: to view the deployments on my dashboard split into pages
So that: the page does not take forever to load and render when there's too many deployments to show.
Describe the solution you'd like: So far, we've been displaying all the deployments in a single table view. The goal is to display
n
deployments at a time in a single page view:Acceptance Criteria: Deployments dashboard supports pagination
Describe alternatives you've considered:
Additional context:
Does this require updates to documentation?: