Improving UX for the paginated compare page

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

!59162 (merged) introduced paginating on the comparison page due to memory concerns.

The following discussion from !59162 (merged) should be addressed:

• @rspeicher started a discussion: (+4 comments)

  @alipniagov @fzimmer This change has negatively impacted us in teamDelivery. We regularly run comparisons in this project in order to see what will be deployed between environments. For example, "What's in the version we're about to promote from canary to production?"

  After this change, we have to manually page through multiple pages in order to see if there are any database migrations, which is a common task for us. We don't even show the full file-list in the drop-down:

  

  So now we have to guess at which page number the migrations might be on, and go through until we can determine that.

Fabian Zimmer Fabian Zimmer 🌱 @fzimmer · 6 hours ago Developer @rspeicher Thanks for raising this. @alipniagov and group memory looked at this from a performance perspective and asked @danielgruesso and @mnichols1 about the UX impact.

I think group source code is in a better position to help you improve this in a follow up.

Edited by Fabian Zimmer 6 hours ago Matthias Käppler Matthias Käppler @mkaeppler · 6 hours ago Maintainer This is fair feedback. Just to suggest a simple mitigation: expose per_page parameter in URL that can be manually set and is capped to the previous value of 75. This means all previous use cases are still supported, but by default we perform less work.

We still need to be careful with this becoming an attack vector. UX is one side of the coin, but we also don't want to enable stampeding herds who request pages that take a minute to render.

Aleksei Lipniagov Aleksei Lipniagov @alipniagov · 6 hours ago Developer @rspeicher Thanks for the feedback!

This is tricky. Previously, we rendered just everything, which could terribly impact memory and sometimes make the page unusable from the user's perspective.

I understand that you had a certain workflow (to search on the page), but I wonder if there is a compromise solution? Maybe to render the list that shows all files on the front page? Or find a better per value?

I agree with @fzimmer that this change is better suited for the domain team ( group source code )?

@rspeicher Could you please open a follow-up for the group source code ?

Edited by Aleksei Lipniagov 5 hours ago Aleksei Lipniagov Aleksei Lipniagov @alipniagov · 5 hours ago Developer can be manually set and is capped to the previous value of 75

@mkaeppler Just a note: in case of the Compare view - there was no cap at all, not even 75 (but now it is possible to set it any value, as well as 75). If I understand correctly, this unlocked certain UX workflows: either search on the browser page (which just loaded everything) or open the dropdown list which wasn't paginating and thus showed all files.

I feel that maybe some UX adjustments may be done with the dropdown list; currently, it is implemented that way that it also paginates and show the portion related to the particular page. Maybe it could show everything, or show everything when rendered on the first page. I feel that domain team could have better ideas.

In general, and looking at the memory spikes, I feel that we need pagination just to prevent us from the memory bloats and, as Matthias mentioned, from the possible attacks.

Edited by Aleksei Lipniagov 5 hours ago

I wonder if we can load the full file list in the drop-down and then automatically jump to the correct page based on the per_page parameter and the file's position in the list. That would at least solve the "blind jumping between pages looking for a specific file" issue.