Left and right navigation to quickly go through issues and commits

[gnu-user]

I'm wondering if something like this has already been added, if not myself or someone else who has the time should try and add this functionality. If you've ever used a system such as Taiga, there's nice left and right navigation buttons to quickly go through issues, especially if you have a lot of them.

Currently with Github, every time you read an issue and comment / close it, you then have to go back to the entire list of issues, remember where you left off and somehow keep track of the next issue to open.

This lack of functionality has bothered me so much that I actually sent Github staff a long email about it over a year ago. They replied but since then have not added this basic functionality, for a reference this is precisely what I'm describing, if you've ever used Taiga they already have this.

As well, a similar type of functionality when you want to quickly go through commits, review changes, pull requests, etc. would also be extremely helpful.

[sindresorhus]

Would definitely be useful, but there were some issues with implementing it previously: #299

Related issue → #152, but only for keyboard shortcuts.

[hkdobrev]

In terms of UI and specific shortcuts, commits in pull requests now have this with Next/Prev buttons and n / p shortcuts.

[gnu-user]

I've read both, maybe I should just pester Github again and see if they'll ever get around to adding it. It's such a simple feature that it boggles my mind that none of their employees have gotten around to implementing it out of frustration when dealing with many issues.

One solution I did think of, would be perhaps scraping the list of issues from the main page and then keeping track of that state when you navigate through issues, this may be a possible workaround.

[hkdobrev]

@gnu-user I could see some reasoning why GitHub are not implementing it (besides that it's mostly useful for maintainers of popular packages or private projects). You can have filtering, and search, and sorting in issues listing and then you go to an issue and it's not always intuitive which issue is next and which is previous. Also, issues and PRs share the incremental IDs. Some users would expect the system to remember their search, others would not, some would even want to go to adjacent ID disregarding if it's an issue or PR, open or closed.

The next/prev buttons on PR commits are quite easier from UX perspective as their predictable - Git commits have parents and therefore you have a linear history in a PR (in most cases).

[fregante]

Closing this as stale, hard to do and because of what @hkdobrev said

[iamandrewluca]

A proposal.

Shortcuts used:

• p for previous
• n for next

Activate shortcuts only when on issue or pull request page.
And document.referrer is a issue list or pull request list page.

GitHub is reflecting in URL filters used for issue or pull request list.
Using document.referrer we can extract the filters and query GraphQL API, to get the list of filtered issues or pull requests, and navigate through them.

User expected flow:

• Go to issues or pull requests list page
• Apply some filters
• Open a issue or pull request from the list
• Expect shortcuts to navigate through issue or pull requests with previous filters

[iamandrewluca]

Status update:

I tried a implementation here https://github.com/iamandrewluca/refined-github/commit/3f54cf968de54a3683d787befdd8e2a8d0bb19d8 I almost want to give up on this 🙂

I started implementation with every type of discussion list in mind. Even when coming from global issue or pull request list.

I consider a discussion any issue pull request or the new beta discussion should work

Navigation can be done using p and n keys or added buttons in discussion header.

It kind of works, there are may be still some edge cases.
Also there is some different behaviour between issues and pull requests
because issues navigation does a full page navigate, pull request do a ajax navigation.

Also there is the case, when you fetch a page from a discussion list,
and a new discussion was added to that list query, on next page fetch,
you may get an issue from previous page. This is a known issue with offset pagination.

We may think but we use cursors. As I found, github cursors are just a offset encoding, a base64 representation of cursor:1, where 1 is the offset.
But still not sure about this. If I fetch a page with after cursor cursor:-1
First item will have cursor cursor:0

Also some context can be found here #2974

Maybe I'll come back to it later, who wants to give a try and improve the implementation feel free to copy it.

@sindresorhus @fregante @gnu-user

[fregante]

Also there is the case, when you fetch a page from a discussion list,
and a new discussion was added to that list query, on next page fetch,
you may get an issue from previous page. This is a known issue with offset pagination.

Yeah that sucks but the only solution would be to fetch after the user clicks the button… which sounds a little slow.

You can open a new draft PR and avoid force-pushing new commits, it makes reviewing harder and causes this mess:

Anyway, it seems to work great and without issues. The code can be improved.

A couple problems I found:

• we can't use the a global cache to store the query because if you open 2 issues from 2 repos they will try to use the same cache and fail. My suggestion is to append parameters to the next-prev links, for example ?query=is:issue

And then you can store the data in the cache with the key results:${getRepoURL()}:${query} by using cache.function

[fregante]

Any updates @iamandrewluca?

[iamandrewluca]

@fregante Unfortunately no. Someday maybe I'll retry the PR. Till then whoever wants, feel free to experiment with info provided in #2974 comments, and https://github.com/iamandrewluca/refined-github/commit/3f54cf968de54a3683d787befdd8e2a8d0bb19d8

I think I blocked myself trying to cover to many cases for navigation.

ps: I'll do a review and try again in weekend, also I'll use unique cache id how you suggested.
ps2: attaching query to navigation links how you sugested should solve all problems

[fregante]

I wonder if this feature can actually exist without it being frustrating. There are multiple possible conflicting expectations of how this should work:

• should navigate by issue number? i.e. Fix crash on pull request pages #333 is followed by Fix alignment of the comment body for PR reviews #334 and preceded by Crash on pull request pages #332
• should it use the exact order of the last seen list or should it query at every navigation?
  • former: we have load the entire list from the API and if the tab remains open for a while, the stored order might become completely out of date.
  • latter: impossible, what does it do if the current discussion leaves the list? (e.g. the list is is:open but the current issue has just been closed)

I think we should give up on this. What I usually do is "Open all" issues and deal with the tabs in order. This has a clear beginning and end and it's visual: the list will stay in the tab bar, not hidden behind Prev/Next buttons.

In the end, I reached the same conclusions that Haralan reached 4 years ago: #343 (comment)

cc @iamandrewluca

[fregante]

I'll close this, I think this feature will give us headaches.

@iamandrewluca if you want the feature, feel free to publish your current code as a standalone, I'm sure many will disagree and accept the compromise:

1. Unfork the repository
2. Drop every other feature
3. Drop the options list
4. Update the readme/manifest/name/deployment
5. Publish as a standalone extension