Currently, our tables use client-side pagination, meaning we get all the table data on the first load of the page, but display only a few entries at a time. The problem with this is fetching all the dogs at once may overload the client. This becomes a noticeable problem as the number of dogs in the database increases.
Solution -> Move pagination to the server. This means only "x" dogs will be returned by an endpoint on any given request. Do this for the Dog Table and Logs tab.
For each table, update the backend API routes to support server-side pagination.
For each table, update the frontend to properly query pages from the API route.
You will notice that the Logs tab does not have frontend pagination. Add the pagination bar according to the Figma and hook it up to the backend.
These routes will have to be updated to support server-side pagination:
POST /api/dogs/search
POST /api/logs/search
For the request to backend you will likely have to add two new properties:
{
pageSize: 20,
page: 1
}
pageSize represents how many entries we want to get back
page represents the page we want to get
the UI will use 1-based indexing
on the backend, you will want to use the $skip and $limit operator in the mongo aggregation query
ensure that filtering and access levels still work as intended
(page - 1) * pageSize is the number of entries you want to skip on the backend
it may be helpful to include these page, pageSize, and count in the response body. They can be used by the pagination UI.
Pagination UI
Currently, the pagination UI displays "Showing x of y Results", where y is the total number of dogs and x is the number of dogs being displayed. This information stays the same as the user moves through pages in the table because x is a total not an index.
Change the pagination UI to display "Showing x of y Results" where x is the index of the first entry and y is the total number of entries that match the filter criteria. We also want to display the current page number as well as the total number of pages.
Eg. "showing 9 out of 30 dogs" then next page would be "18 out of 30 dogs", …
Eg. "X out of Y pages"
You can likely calculate these totals on the backend and include them in the body of the response.
Description
Refactor pagination
Currently, our tables use client-side pagination, meaning we get all the table data on the first load of the page, but display only a few entries at a time. The problem with this is fetching all the dogs at once may overload the client. This becomes a noticeable problem as the number of dogs in the database increases.
Solution -> Move pagination to the server. This means only "x" dogs will be returned by an endpoint on any given request. Do this for the Dog Table and Logs tab.
You will notice that the Logs tab does not have frontend pagination. Add the pagination bar according to the Figma and hook it up to the backend.
These routes will have to be updated to support server-side pagination:
POST /api/dogs/searchPOST /api/logs/searchFor the request to backend you will likely have to add two new properties:
pageSizerepresents how many entries we want to get backpagerepresents the page we want to get$skipand$limitoperator in the mongo aggregation query(page - 1) * pageSizeis the number of entries you want to skip on the backendpage,pageSize, andcountin the response body. They can be used by the pagination UI.Pagination UI
Currently, the pagination UI displays "Showing x of y Results", where y is the total number of dogs and x is the number of dogs being displayed. This information stays the same as the user moves through pages in the table because x is a total not an index.
Change the pagination UI to display "Showing x of y Results" where x is the index of the first entry and y is the total number of entries that match the filter criteria. We also want to display the current page number as well as the total number of pages.
You can likely calculate these totals on the backend and include them in the body of the response.
Acceptance Criteria
Other Notes