PWA: First implementation of offline mode

[BhasherBEL]

This PR (currently a draft) aim to implement offline PWA. I'm using miniflux a lot when traveling, and network is not always stable in such conditions. Other users seems to be interested by this, see #1395.

However, multiple things need to be done before this can me merged, and some are probably subject to discussion.

• [X] Opt-in trough user setting (as it can increase network usage and latency)
• [ ] Warn the user that he's offline/using a cached version
• [ ] Define a cache strategy. For now, it "stupidly" cache /, /unread, /offline and visited pages. But the main interest is obviously to cache unread articles. I can imagine different strategies here:
  • Cache every unread article (can be a lot!)
  • Cache n most recent unread article
  • Allow to cache article individually (maybe in addition of the previous strategy)
  • Cache starred articles
  • Let user decide (would probably require too much work)
  • ...
  • [ ] Define actions that cannot be done offline (mark article as read, change user settings, ...) and prevent the user to do them.
  • [ ] Probably many other things?

Any thought on this is welcome.

---

Do you follow the guidelines?

• [X] I have tested my changes
• [X] There is no breaking changes
• [ ] I really tested my changes and there is no regression
• [ ] Ideally, my commit messages use the same convention as the Go project: https://go.dev/doc/contribute#commit_messages
• [X] I read this document: https://miniflux.app/faq.html#pull-request

[woj-tek]

Just a 3c - I think that "Cache n most recent unread article" would make most sense (indeed I do have thousands of unread articles reaching even 2 years back)

Define actions that cannot be done offline (mark article as read, change user settings, ...) and prevent the user to do them.

Do you think it would be possible to enable (and cache for when the network is available) actions like marking article as read or starring it?

[BhasherBEL]

Just a 3c - I think that "Cache n most recent unread article" would make most sense (indeed I do have thousands of unread articles reaching even 2 years back)

I agree. On my second commit, I cached the first /unread page. I would say that's reasonable for most case, and also prevent having too much settings. Afaik it's up to 50 articles with default config.

Define actions that cannot be done offline (mark article as read, change user settings, ...) and prevent the user to do them.

Do you think it would be possible to enable (and cache for when the network is available) actions like marking article as read or starring it?

It's probably feasible, but I don't know if it's really a good idea. As it rely on browser's cache it's also less readable for a normal user, and I'm no sure if it can send the updates when it connect back to network, but you're not on the PWA.

Maybe this could be thought for a second version?

[woj-tek]

I agree. On my second commit, I cached the first /unread page. I would say that's reasonable for most case, and also prevent having too much settings. Afaik it's up to 50 articles with default config.

My use-case is somewhat odd I'd guess but I have switched to 10 items per page so I can have all items visible in one go without need to scroll, which is quite handy (all other controls remain in the same place helping with muscle memory) :-)

It's probably feasible, but I don't know if it's really a good idea. As it rely on browser's cache it's also less readable for a normal user, and I'm no sure if it can send the updates when it connect back to network, but you're not on the PWA.

Uh, this definitely sounds quite complicated.

[BhasherBEL]

My use-case is somewhat odd I'd guess but I have switched to 10 items per page so I can have all items visible in one go without need to scroll, which is quite handy (all other controls remain in the same place helping with muscle memory) :-)

That's a fairly fair use case imo, that could also apply to the many differents way we have to display the same article.

Maybe for a first "easy to understand" implémentation,, it could just cache (maybe with a way to limit it on time/size?) any article that got previewed? That way, if youu visit 5 pages, it will cache all of them.

Another thing that could complexify the implementation of the cache is that a same article is accessible with different URLs, typically /unread/entry/2248, /unread/feed/26/entry/2248 or /unread/category/2/entry/2248 are the same article, but they would need to be cached separately.

[woj-tek]

Maybe for a first "easy to understand" implémentation,, it could just cache (maybe with a way to limit it on time/size?) any article that got previewed? That way, if youu visit 5 pages, it will cache all of them.

Hmm... somewhat sensible but I think I'm again an outlier here. Quite a lot of the feeed items area from "heavy" news feeds (I have about 4-5 of them) and with them the item itself mostly have an excerpt only (I'm pondering an idea to somehow bolting a retrieval mechanism into miniflux as a service so I would get whole article without the need to open the page) and I usually just swipe majority of them away on mobile (which simply breaks when I loose network coverage).

Therefore solution with caching only visited pages wouldn't be that convenient for me either. Though I understand the need to balance the size of cached data and with those busy feeds it could quickly get out of hand.