Implement archive navigation and read previous/next feature

[psilabs-dev]

Issue: #1187

This is a preview (docker image link) of an implementation for reading previous/next archives without going back to the index page. Feel free to try it out and give feedback!

To aid in the browsing experience, I've added two keyboard shortcuts:

• shift+L/R: go to first page/last page
• square bracket: read previous/next archive

Additionally, any action that results in going back from page 1 or going forward from the last page will automatically redirect to the previous/next archive.

Currently there are some limitations which I've decided to impose to make this happen:

1. navigation support is limited to archives from the search results/datatables page; i.e., this is not supported when reading archives in the carousel or when pasting an archive link and visiting it directly (no referer). Mainly the reason I want to limit it to search results is because I think that's where most users would be using it. However, it is possible to extend this feature to support carousel navigation, that would be a second-phase feature.
2. archive-jumping functionality is supported only when the user is not in full-screen viewing mode. I've tried changing archives while in full-screen, but it's just really ugly with the browser kicking you out of full-screen mode when changing URLs. It's probably possible to change archives while maintaining full-screen, but that might be a second-phase feature too. (though I would very much like to implement this)

There are still some concrete things to add to the current PR. There's the actual icon to click to read previous/next (currently the only way to directly jump is with squre brackets, I actually forgot about this because I'm used to keyboard navigation lol), I'm thinking of using forward-step. The other thing to do is exception handling in the case of missing archives or general changes in datatable results. Then clean up on some logic/remove debt.

We might also want to discuss how to integrate tankoubons in this PR too.

---

Design

There are two components to this PR: archive navigation and reading previous/next functionality.

Archive navigation refers to the functionality of keeping datatable (DT) state when moving between archives. When reading archives, we need to know what archives are ahead of us/before us, at all times, while navigation is supported, and this information must be persisted through a reading session.

Further, this foresight must extend beyond the current DT page; if a user reaches the last archive of page 1, they should be able to move to the first archive of page 2, of whatever DT search result was yielded from the search filter applied at the point of entering reader mode from the search page.

This foresight logic is implemented at the first/last archives of the DT list, and a fetch for the upcoming DT list will be performed if not already cached, keeping the number of archives IDs stored at around 200-300 (or the search limit) at any given time.

Read previous/next functionality is based on the implementation of navigation, but its logic is straightforward.

A consequence of implementing read previous/next is the problem of returning-to-index. Without the DT query/filter, we would always return to page 1 and lose our search filter. By maintaining DT query state throughout the reading session, the navigation support will also allow us to go back to the correct DT index page.

This implementation persists these (new) variables to local/session storage:

• navigationState (session): to enforce when navigation should be supported
• datatablesPageSize: part of maintaining DT query state
• currentSearch: same reason as page size
• selectedCategory: same reason as page size
• currDatatablesPage: same reason as page size
• currArchiveIds: for reading previous/next
• previousArchiveIds: pre-emptively loaded when user approaches end of search results
• nextArchiveIds: same reason as previous archive IDs

Also the commit 04e6e01 fixes some rare instance where you get "Fetch API cannot load http://localhost:3000/api/minion/2301 due to access control checks" errors. I considered putting this as a separate PR, but I don't think anyone would encounter this bug unless you're rapidly swapping between archives, which is enabled by this feature

[Asinin3]

Awesome work. I haven't tested (yet), but this is exactly what I was hoping for. Does the Random gallery function work with it (R Keybind)? Also, would you consider adding shift+A/D to go to previous/next gallery? A/D already go back/forward pages so it would make sense. Then you could do everything with the same keys near eachother.

[psilabs-dev]

Does the Random gallery function work with it (R Keybind)?

This feature doesn't support the R-key unfortunately, because I'm not sure how these functionalities are compatible with each other. Currently the feature is limited only to galleries from search query results, so it would be disabled if you press the r-key, use direct navigation, or enter from carousel.

adding shift+A/D to go to previous/next gallery

A/D should work with this. The read previous/next gallery is wired onto the previous/next page functionality, so anytime you go out of bounds of the current gallery using existing page switching methods, you'll end up in the neighboring one.

[psilabs-dev]

fffff Should be stable 🤞

Fixed the last of the bugs (that are caused by me: If you encounter carousel and stat loading type errors while going back to index, that is not a navigation issue that is an existing safari issue!). The main big one was the slow loading of index page on browser back, because changing to another archive erased some data (see psilabs-dev#39). Now browser back should always return to the index page, and it "should" use bfcache and not take any longer than before PR.

Below is the flowchart for the expected behavior of read next archive and reader initialization if it helps at all (AN stands for archive navigation):

A CSS change was made at 968d372 to remove the undesirable behavior for small (mobile) clients:

I think this is all I reasonably do for this feature for now. After wrestling with navigation + full screen for a while, I think (whether it be true or out oif ignorance) it would be better if we turned the reader page to be an SPA, within which we swap between archives more seamlessly. Any way that removes the need to reload the HTML that kicks the user out of full screen would help.

The other thing to do is exception handling in the case of missing archives or general changes in datatable results

Also I know I said this lol, but do we want to handle this? I feel the chances of encountering this are pretty low for a usually single user so I haven't really had to think of this. Main reason is that addressing this case would add more state and tracking.

[psilabs-dev]

undrafting this as no changes are planned at this moment

[alethiophile]

I had planned to implement similar functionality as this for tankoubons, as part of my tankoubon UI project. It seems like I should probably just adapt this instead?

[Difegue]

I had planned to implement similar functionality as this for tankoubons, as part of my tankoubon UI project. It seems like I should probably just adapt this instead?

Not quite I think; I haven't given the tank UI PR a deep look yet but ideally the aggregation of archives within the reader should use the interfaces that were added as part of the ToC implementation.

For switching from one tank to the next though, I think that's where this PR would come in.

[psilabs-dev]

Ok, seems there is a bug caused by the slideshow functionality. Will have to look into this.

[psilabs-dev]

Previously when slideshow was enabled, it would stop at the first page of the next archive. I consider this buggy behavior, so now slideshow will persist across all archives, like a multi-archive slideshow.

[psilabs-dev]

After thinking about it a bit, I've decided to remove the popstate logic, so that archive navigation pushes archives into history, and browser-back will pop state/go to the previously read archive (instead of going straight back to index). This is in contrast to previous logic, where users may navigate between 20 archives, but if they hit BB they instantly go back to index (though it might not have worked 100% of the time).

This means that now the only way to go back to index page (immediately) would be to click on the "return to index" icon. If we want to have a keyboard shortcut, I would prefer using an alternative to browser-back, and keep archives in browser history.

@Difegue currently navigation uses keypress "["/"]", but do you otherwise have a preference for French keyboards/compatibility? We can also do shift+a/shift+d.