Geo Replicables: SPA and Pagination
What does this MR do and why?
Closes Geo Replicables List: Add ability to store pagi... (#535692 - closed)
This change does two significant things:
- Updates the list view to properly act like an SPA and simply update the GraphQL query when the params change
- Store the pagination in the URL Query
Previously, every time the filters were changed in the filtered search it would trigger a full page reload. This is quite inefficient as we have Apollo to manage the state changes for us and can quickly get the new data from the API without a full page reload.
Screenshots or screen recordings
| Before | After |
|---|---|
| Before | After |
How to set up and validate locally
Setup Geo (optional)
Important: To properly test Geo you will need a separate GDK setup. Setup is straightforward but takes some time. Another option is to validate the code functionally and if needed schedule a call to sync and I can screen share my instance.
- Ensure no other GDKs are running.
gdk stop/gdk kill - Open an empty directory and install and run Geo with the one-line command found on the Easy installation instructions
- Access your primary and secondary Geo instances via
127.0.0.1:3000and127.0.0.1:3001.
Testing
- Access your primary GDK Geo Page (
127.0.0.1:3000/admin/geo) - Scroll down to the very bottom
Replication detailssection - Click one of the blue links (ex:
Project Repositories) - Ensure the filtered search allows for filtering and doesn't fire full reloads every time a filter is change
- Ensure that changing the option in the Combo listbox DOES trigger a redirect
- Ensure that the pagination works correctly and is stored in the URL even after refresh
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #535692 (closed)