Automatically mark posts as read when you scroll past them

[mcmikemn]

It would be nice if posts were automatically marked as "read" when you scrolled past them. I'm not a coder so I have no idea if this is a reasonable request - sorry if it's not!

[asimons04]

I think I have all of the necessary components to add something like that. It would have to be throttled, though, to avoid spamming the API if you're rapid scrolling.

Probably something like 2 seconds in the viewport should be a decent compromise, but I'll have to implement it and fine tune from there.

[mcmikemn]

Wow, cool! Pre-thanks. :)

Regarding spamming the API with rapid scrolling: could you locally store every post that has been scrolled past (so speed isn't an issue), and then pass them to the API at a more controlled pace? A problem with this method could be that the user might want them marked as read before they actually get marked as read - but if the alternative is to require a post to be on the screen for X seconds before being marked as read, then a fast-scrolling user might not appreciate/use the feature anyway. Though 2 seconds per screensful of posts isn't much to wait for.

[asimons04]

could you locally store every post that has been scrolled past (so speed isn't an issue), and then pass them to the API at a more controlled pace?

Short answer: yes.

Method 0: Kind of what I described, but I could track and trickle them in to the API. That should work for the current version that supports 0.19.0 through 0.19.3.

Method 1: For a while now I've been planning to re-engineer the whole thing be able to work as an offline PWA, but I am hitting limits using Session and Local Storage. After a lot of thought, I finally settled on using PouchDB as the storage library and backing it with the browser's Indexed DB. That should allow practically unlimited storage where Local/Session storage would max out at 5 MB per key. 5 MB sounds like a lot until you want to start doing everything locally, and then it gets messy splitting data around multiple keys.

With the offline model, everything would stay local and update in batches in the background.

Since PouchDB can directly sync with CouchDB, I'm also exploring adding Couch to the Tesseract's server-side components. That would allow settings, lists, groups, etc to be synced across devices.

Method 2: The 0.19.4 (or maybe 0.19.5) API introduced the ability to pass an array of post IDs to the API to mark multiple as read in the same call. Once I add support for the newer API calls, I could just track the post IDs that have been scrolled past and submit those as an array every 30-60 seconds or so (while also marking them as read locally). Right now, though, the current version only supports up to 0.19.3 which only supports a single post ID per call.

In the short term, I'll probably go with method 2. Life's been chaotic the last month or so, and I've fallen behind on adding support for 0.19.4+, so that'll be a good place to start.

Since the upcoming Svelte 5 is going to require quite a bit of work to use their new event listener syntax, I'm not going to start on offline support until that's done.

[mcmikemn]

I'm out of my wheelhouse already, but option 2 sounds good to me. Whenever you get a chance, if you get a chance. :)

[asimons04]

It's happening...

It's functional now, but I'm still fine-tuning the behavior of it. Unless something catastrophic crops up with the current implementation, it should be included in the 1.4.16 release :)

[mcmikemn]

Wow! Thanks!

[asimons04]

1.4.16 released with this feature included.

If you're using the hosted instance, the latest version is deployed there. If you're self-hosting, you should be able to pull the :latest, :1.4.16, or :v1.4.16 tag. Otherwise, your instance admin will need to update.