Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Speed up PR list and other improvements #1737
This PR refactors the PR list to:
Use GraphQL for loading
By using GraphQL we can load only the fields we're interested in, which speeds up our queries.
Use data virtualization so that only visible items will be loaded
Previously, when the GitHub pane was opened, all pull requests were loaded. This could take minutes for repositories with a lot of pull requests, and the whole time they were loading VS would be slow.
With this PR, only the first 100 PRs will be loaded when the GitHub pane is shown, which is a single request. When the user scrolls down, more PRs will be loaded on demand.
Display a message when no items found
We currently have two messages:
When no filters are active and no PRs are found:
When filters are active and no PRs are found:
The author filter is now searchable:
Unfortunately because we're now only loading the first page of results, we don't have a full list of all users that have opened a PR, instead we use the GraphQL "Assignable Users" endpoint to get a list similar to on .com and allow the user to also select logins that they enter that aren't on that list.
Depends on #1712
@grokys Dogfooding this and am so impressed with all the improvements to the PR list!
Leaving some feedback and questions. I know this is still WIP so apologies if you're already addressing some of these things.
General feedback (and screenshots
referenced this pull request
Jun 29, 2018
.com allows to sort by "Least recently updated". It's interesting because it highlights which are the more "active" PRs. There could be "old" PRs that just take a while, but still get updated regularly.
On the other hand, sorted by "Newest" makes the list much more constant/predictable. There is no random re-ordering and new PRs just show up at the top. Maybe good to show that as the default.
Yeah, I think if we're settled on sorting by recently updated, then we should consider reflecting that in the timestamp (like what you mentioned that .com does.)