[Feature]: Change default dependents and GH used by to top 50 sorted by downloads/stars and allow users to see all

[JonDouglas]

Related Problem

No response

The Elevator Pitch

We should increase this job/number to 50 by default and then provide a means to allow someone to "view all" which can load a separate page or even download a file that includes the entire used by list. These lists should still keep their sorting by popularity.

Other examples:

https://www.npmjs.com/package/react?activeTab=dependents

https://www.npmjs.com/browse/depended/react

Additional Context and Details

No response

[stephentoub]

Is just upping the number hard to do, or is it as simple as changing a constant somewhere? Increasing the number would be very helpful, even if the other part of downloading the whole list was saved for later.

[joelverhagen]

Is just upping the number hard to do, or is it as simple as changing a constant somewhere? Increasing the number would be very helpful, even if the other part of downloading the whole list was saved for later.

Upping the number is easy, the const is here:

NuGetGallery/src/NuGetGallery.Core/GitHub/NuGetPackageGitHubInformation.cs

Line 12 in b55d335

public const int ReposPerPackage = 5;

A separate page with pagination and proper UX to explore the whole list is more costly. Downloading the list would probably be easy. UX is less of a concern for that, just picking a response model that we can commit to long term and perhaps setting up caching in our gateway.

What number shown on the existing page would work for you @stephentoub, @JonDouglas? Others are welcome to comment too of course!

cc @OliaG, NuGet PM

[stephentoub]

Thanks, @joelverhagen. Something at least, say, 20, would be helpful. 5 is just so small, it only provides a taste, and ends up being dominated by the handful of heavyweight consumers... having more helps to get past that and show a broader swath of who's using it. If we're not overly concerned with the page being longer, a number more like 50 would be welcome. Once the full list is available somewhere / somehow, I care less about the list on this page, as I can just grab the full list and consume it however makes sense for my current needs.

[JonDouglas]

i think starting w/ 20 should be able to answer most questions while limiting the page scroll.

thanks for finding that constant @joelverhagen! no idea how i missed it at the time as i looked for a good 15 minutes.

is there another one for the nuget reference portion?

this small change would be beneficial until further design on expanding to 50(likely needs tabs or less whitespace) and providing pagination / a data source for all.

[joelverhagen]

is there another one for the nuget reference portion?

NuGetGallery/src/NuGetGallery.Services/PackageManagement/PackageService.cs

Line 33 in b55d335

private const int packagesDisplayed = 5;

This one is more sensitive because there is a SQL query behind the scenes to populate this. We had some non-trivial perf issues due to query plan caching (it was a whole ordeal) -- thus the book sized comment 😅:

NuGetGallery/src/NuGetGallery.Services/PackageManagement/PackageService.cs

Lines 167 to 169 in b55d335

	// We use OPTIMIZE FOR UNKNOWN by default here because there are distinct 2-3 query plans that may be
	// selected via SQL Server parameter sniffing. Because SQL Server caches query plans, this means that the
	// first parameter plus query combination that SQL sees defines which query plan is selected and cached for

But I imagine 5 vs 20 is not a big deal here either since the big work is getting the sorted list of package dependents, not the final step of retaining 5 or 20 results from the top.