If a library has a lot of vendors, say a few thousand, the vendor page load is extraordinarily slow. There is a lot of data being pulled into the page that is perhaps unnecessary. It would be worth considering changing this page to a table that lists the vendor name with action buttons for New, Edit, Receive. The vendor name could be a link to the vendor detail page that then displays the baskets. The table could include other bits of data deemed useful over time. If the table was sortable and searchable, it would be far more useful. If a library has this many vendors and associated baskets, the entire page is cumbersome.
I think this would not be solved by a table alone, it would require switching to the REST API to give a real performance boost. I like the way it currently allows to see on a glance which vendors have open baskets - maybe this could be incorporated into an updated result list display. We'd also might want a different more detailed display for a single result.
This was kind of talked about in bug 34509 - not being able to create a basket when there were too many vendors. (We are also a library with thousands of vendors.) So (if I am reading that bug right) it was changed to rely on the Rest API to generate the dropdown list of vendors. Would that code be able to help resolve this same vendor page load?
I don't think we have any issues with loading times (we don't have that many vendors) but just from a user experience perspective, I've always found it strange that there isn't a page that simply lists vendors without all of their associated baskets beneath. I'd love a table with maybe counts of total open vs closed baskets.