BDMS-776: Increased the export hook pageSize from 20 to 500 on well list page

[TylerAdamMartinez]

Why

This PR addresses the following problem/context:

• The export feature was making many paginated requests to the backend using a default pageSize of 20.
• Large exports required going through ~69 pages to generate a single CSV export.
• This resulted in slower export times due to the repeated frontend ↔ backend round-trip and request overhead.

How

Implementation summary - the following was changed/added/removed:

• Increased the export hook pageSize from 20 to 500.
• This reduces the total number of requests required during export generation.
• Fewer requests improve performance by reducing:
  • HTTP request overhead
  • frontend processing time
  • backend pagination overhead
  • repeated serialization/deserialization work
• Local speed test results:
  • pageSize: 20 → 8.21s
  • pageSize: 500 → 3.53s

Notes

Any special considerations, workarounds, or follow-up work to note?

• A larger pageSize improves performance for the current implementation, but the export process still relies on multiple paginated API requests from the frontend.
• For additional performance improvements, we could implement a dedicated backend export endpoint that performs the export in a single request

[TylerAdamMartinez]

Does the export need to exactly mirror the currently filtered/paginated list view?

[github-actions]

Preview Deployment

Preview URL: https://preview-tam-bdms-776-auejgdbofq-uc.a.run.app

Note: This preview uses the staging API endpoints.

[TylerAdamMartinez]

Does the export need to exactly mirror the currently filtered/paginated list view?

@jeremyzilar This PR now includes the same search parameters as the search, so the exported sheet will return the same search results

[github-actions]

Preview Deployment

Preview URL: https://preview-tam-bdms-776-auejgdbofq-uc.a.run.app

Note: This preview uses the staging API endpoints.