Loading an org with 2000+ packages (e.g. https://npmx.dev/@fontsource) can cause the site to choke on a fresh cache. I think there's also an additional bug where useOrgPackages doesn't return download counts (because the underlying NPM API doesn't?), so sorting by download counts is also broken.
Ideas
I might look into contributing a fix by looking into refactoring useOrgPackages to use some other NPM APIs and stitch them together. But I want to propose that we should revisit the data model for this project first and distinguish List and Get models distinctly.
We currently use a huge NpmSearchResult interface that has everything, but it might be good to make some abstractions like PackageSummary (List) and PackageDetails (Get) to tighten things up and make data access clear so FE doesn't access all sorts of things that lock us into a single NPM API type.
Redesigning useOrgPackages for PackageSummary with a smaller API surface is much easier to design for (and maybe easier to stitch random APIs together) and makes it very clear what FE actually uses vs random fields that might or might not be populated.
I know this conflates multiple separate bugs and issues, but I wanted to get a bit of a discussion going on this topic first before making specific issues. I also may be misunderstanding parts of this codebase 🙏
Edit: I noticed we use SlimPackument for certain parts of the site, which is along the lines of what I'm looking for. But not necessarily for listing 👀
Loading an org with 2000+ packages (e.g. https://npmx.dev/@fontsource) can cause the site to choke on a fresh cache. I think there's also an additional bug where
useOrgPackagesdoesn't return download counts (because the underlying NPM API doesn't?), so sorting by download counts is also broken.Ideas
I might look into contributing a fix by looking into refactoring
useOrgPackagesto use some other NPM APIs and stitch them together. But I want to propose that we should revisit the data model for this project first and distinguishListandGetmodels distinctly.We currently use a huge
NpmSearchResultinterface that has everything, but it might be good to make some abstractions likePackageSummary(List) andPackageDetails(Get) to tighten things up and make data access clear so FE doesn't access all sorts of things that lock us into a single NPM API type.Redesigning
useOrgPackagesforPackageSummarywith a smaller API surface is much easier to design for (and maybe easier to stitch random APIs together) and makes it very clear what FE actually uses vs random fields that might or might not be populated.I know this conflates multiple separate bugs and issues, but I wanted to get a bit of a discussion going on this topic first before making specific issues. I also may be misunderstanding parts of this codebase 🙏
Edit: I noticed we use
SlimPackumentfor certain parts of the site, which is along the lines of what I'm looking for. But not necessarily for listing 👀