Left and right navigation to quickly go through issues and commits #343

Status update:

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

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 https://github.com/sindresorhus/refined-github/pull/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

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: <img width="250" alt="" src="https://user-images.githubusercontent.com/1402241/81598441-97a26a00-93c7-11ea-8a10-699058fd83f9.png">

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

Any updates @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

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. #333 is followed by #334 and preceded by #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: https://github.com/sindresorhus/refined-github/issues/343#issuecomment-267151687

cc @iamandrewluca

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