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

[psilabs-dev]

tbh not too sure about being able to jump around so easily. I was considering doing a double-tap for archive hopping when using arrow keys, so I might also experiment with the accessibility here

the other problem I ran into when I was using is it's kind of hard to know when you're changing archives vs changing pages, you might be reading something and then you're reading something else 🤔

[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.