Regression: listing repositories is unusable for any significant amount of repos

[shana]

As much as I hate vague issue titles, it's pretty much that. Any user who has access to a significant number of repos (even if they only own a few, they might have org access with large numbers of repos) will have a bad time when listing repositories.

This is me loading the clone repo dialog from the 2017 start page. It takes two minutes to get anything to show up on the list:

There are two main problems here, which together make the UX poor:

1. No caching - every time the dialog opens, it runs the query again without showing previous results
2. No streaming - the list is only populated when all results come in

A side effect of no caching and re-running the full query every time is that it might exhaust API rate limits and lock users out temporarily, depending on how much many api calls are happening. One of my attempts at loading the list resulted in a 403 forbidden:

[jcansdale]

Azure DevOps tackles this problem by initially showing a list of repositories recently contributed to. There is a separate button to load the full list of repositories. This way the user can be prepared for a longer load if the repository they're after isn't on the recently contributed to list.

I think this is a pretty reasonable solution. It's simple and lets the user know what's going on. If streaming and caching GraphQL will take a while to develop, maybe we could do this as a interim solution?

[jcansdale]

Here are some timings: