Added Pagination For Team Listing Page

[shailesh-google]

Fixing Performance issue of team list page by Adding Pagination.

Fix For #1150

[codecov]

Codecov Report

❌ Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 44.24%. Comparing base (8227260) to head (cf4afcf).

Files with missing lines	Patch %	Lines
...e_teams/src/Entity/ListBuilder/TeamListBuilder.php	0.00%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##                3.x    #1212   +/-   ##
=========================================
  Coverage     44.24%   44.24%           
  Complexity     3070     3070           
=========================================
  Files           344      344           
  Lines         11235    11235           
=========================================
  Hits           4971     4971           
  Misses         6264     6264           

Files with missing lines	Coverage Δ
...e_teams/src/Entity/ListBuilder/TeamListBuilder.php	0.00% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[boobaa]

Hi @shailesh-google ,

Thank you for this pagination patch, which I just gave a try. As a test, I have a local site with drupal/apigee_edge:3.0.13 which is configured to fetch ALL the Apigee-related data for the /teams page from a local endpoint (to eliminate both the network latency AND the time Apigee Edge/OPDK would need to collect and return the data), with some 10k (!) teams.

• With both this and PR#1210 applied, first 1k of the 10k /teams page load time: 5.1/3.2 secs
• With both this and PR#1210 applied AND a custom patch (that uses the NullBackend for TeamStorage's cache) also applied, first 1k of the 10k /teams page load time: 2.6/1.4 secs

Also worth noting that while this pagination does decrease the page load times quite a bit, it also removes the possibility to find a particular team by (part of) its name using the browser's find-in-page functionality, as one might have to paginate thru quite a bunch of pages until the correct team is found. The situation is a bit better if the user knows the WHOLE name of the team (or searches for the first part of it), as it's still possible to order this list by the teams' name or status.

To mitigate this, it would be nice to have Views support for listing teams, so the sitebuilder could add some exposed filters as needed.

[shishir-intelli]

Thank you, @boobaa for testing this PR and providing the excellent performance metrics.
The results confirm that this pagination approach is the best solution for addressing the high latency associated with listing 10,000 teams.

We agree that pagination makes browser-based search (find-in-page) a significant issue.

• Views Support: Adding Views support for listing teams is a great idea for advanced filtering, but we are not planning this enhancement currently.
• Sorting: We recognize the need for better discoverability. We will create a separate ticket specifically to implement sorting the list by team name, if feasible within Drupal's current architecture.

If you are satisfied with the performance gains, please provide your LGTM (Looks Good To Me) for both PRs so we can merge and release them.

Thanks again for your effort.

[divya-intelli]

Hi @boobaa @shishir-intelli ,

We can give administrators more control over the paginated team listing by adding an Admin Configuration page. This new configuration would offer two key options:

• Setting a custom limit for the number of teams displayed on a single page, overriding the current 1,000 limit.

• An option to turn off pagination, displaying all teams at once.

[boobaa]

Hi @divya-intelli ,

Thank you for the ideas, they totally make sense. I'm a bit concerned about turning off pagination, tho: would that mean we're back to square one regarding page load times?

In other words, would this solution mean that the sitebuilder MUST choose which finger to bite:

• They can configure pagination to 1000, 100, 50 or any number of teams per page to have some "good-enough" page load times, but sacrifying the search capability, OR
• They can configure the pagination to infinite (so all teams are displayed on one single page, eg. for searching), but sacrifying the page load time?

So is it either this or that, but we cannot satisfy BOTH requirements (search AND "good-enough" page load times)?

[shailesh-google]

Hi @boobaa,

Following up on our previous discussion regarding the usability of the teams list: I have implemented the Search Feature to team listing page.

This addresses the concern you raised about navigating 20k+ teams. With this update, users can now locate specific teams without needing to manually click through paginated results, restoring the core functionality needed for high-volume accounts.

Please refer to PR #1216 for the implementation .