Add pagination to surveys lists

[davidbgomes]

📌 References

• Issue: Closes add pagination

📝 Implementation

• Added pagination to all surveys lists

📹 Screenshots/Screen capture

🔥 Notes to the tester

[9sneha-n]

@davidbgomes. We need changes in the PR to reflect the following :

1. There is a filter logic applied on survey list based on the type of survey. The page details do not refelect this and show incorrect count

2. Looks like the page details like count is not refreshed in country list, it shows the count of PPS Survey list

3. The PPS Survey list has 2 filter by options, when the filter is applied only the first page is filtered. I do not think this is acceptable behaviour. All the pages need to be filtered.

I would apply the paging logic only to lists that would actually be large in number, which I am guessing is only patient list @MiquelAdell Please provide your inputs here. And for the lists that have paging enabled, we will provide only search functionality, where we will go directly to the backend, so we wont be effected by the pagination.

[9sneha-n]

@davidbgomes see the code above, the survey list is getting filtered. The page details need to reflect this filtering.

[davidbgomes]

Thanks Sneha! Oh I didn't account for the filtering outside the API. But in this case we can't use the API's pagination altogether, it will always be wrong on those cases. I'd need to redo and get all data at once to do our own pagination with the cached data, which performace-wise makes the pagination useless. Even if it's only for the Patients List the problem is there as well. What do you think @9sneha-n @MiquelAdell ?

[9sneha-n]

Thanks Sneha! Oh I didn't account for the filtering outside the API. But in this case we can't use the API's pagination altogether, it will always be wrong on those cases. I'd need to redo and get all data at once to do our own pagination with the cached data, which performace-wise makes the pagination useless. Even if it's only for the Patients List the problem is there as well. What do you think @9sneha-n @MiquelAdell ?

@davidbgomes We can solve this issue in 3 ways

1. Save UI page numbers/count and server page numbers/count separately and update the UI page numbers/count only based on filter.
2. Do not have page numbers in UI, have infinite scrolling. Fetch , a page from server, when the user scrolls down, show a loader and fetch the next page.
3. Do not have pagination at UI at all. Just fetch the surveys in a paginated manner from server - which would cause performance issue but ensure we never crash.
   I would strongly recommend the second option, i think it would be the quickest and most performant solution. @davidbgomes @MiquelAdell Do you see any concerns with option 2?

[davidbgomes]

Thanks Sneha! Oh I didn't account for the filtering outside the API. But in this case we can't use the API's pagination altogether, it will always be wrong on those cases. I'd need to redo and get all data at once to do our own pagination with the cached data, which performace-wise makes the pagination useless. Even if it's only for the Patients List the problem is there as well. What do you think @9sneha-n @MiquelAdell ?

@davidbgomes We can solve this issue in 3 ways

1. Save UI page numbers/count and server page numbers/count separately and update the UI page numbers/count only based on filter.
2. Do not have page numbers in UI, have infinite scrolling. Fetch , a page from server, when the user scrolls down, show a loader and fetch the next page.
3. Do not have pagination at UI at all. Just fetch the surveys in a paginated manner from server - which would cause performance issue but ensure we never crash.
   I would strongly recommend the second option, i think it would be the quickest and most performant solution. @davidbgomes @MiquelAdell Do you see any concerns with option 2?

@9sneha-n the problem is that you could be fetching a page from the API that would then return empty or with fewer results because in-between we would filter them. In my opinion the infinite scroll would add complexity to it, but the base problem would remain. Option 1 would be too complex to handle two different pagers I think. I don't think I understood the option 3, but I think we could do a in-between solution, the other one you said in the meeting, where we fetch all and do our pagination. In this case where the API call isn't the final result is what is quickest to do and most reliable I think. Let me know what you think