Our web app should support offline mode by replacing our current cache update logic with a normalized local DB containing tags, subscriptions, and entries.
When offline mode is off, the local DB should be in-memory and should just contain the data we've loaded (ideally with cache timeouts). We should do pagination as-usual, only fetching the data we want to display immediately, but saving any data for fast page transitions.
When offline mode is enabled, the local DB should be stored in IndexedDB. There should be a configurable storage (default=100MB) and time (default=30 days) limit for how long we will keep entries. There should also be a separate limit for read entries (default=2 days). We should pre-cache all tags and subscriptions in offline mode, along with the entries matching the configuration.
If we hit the storage limit we should delete the oldest articles from the cache until we're at the limit (we should try to do this in one query - lookup how many entries we would need to delete from the cache and then delete them all at once).
I think the best way to do this is with Tanstack DB: https://tanstack.com/db/latest
This should let us define fetching logic and automatically use the local DB first while fetching additional data in the background. We will need some translations between our cursors and Tanstack DB's offsets (we will likely need to store a cursor per list we're paginating).
Our unread entry logic is very complicated, and we can't do the easy thing here (calculating unread from DB counts) because we won't necessarily have all of the entries or subscriptions cached. To handle this, we should store the counts from the server for each list (All, Saved, Starred, each tag, each subscription), and a local delta based on our changes to the read counts.
We will likely need a persistent update queue (also Tanstack DB?), so we can keep track of updates we need to apply to the server and restart them when we're online. We can add to the update queue in our optimistic update logic and remove from it when the mutation completes? Then we should be able to calculate deltas dynamically by reading the queue.
Cache update logic is complex, so we need 100% of reads to use Tanstack DB when appropriate (tags, subscriptions, entries, counts) and to not mix Tanstack DB and direct usage of React Query.
Tanstack DB only runs client-side so we'll need to hydrate via SSR but not actually render until the client side.
Our web app should support offline mode by replacing our current cache update logic with a normalized local DB containing tags, subscriptions, and entries.
When offline mode is off, the local DB should be in-memory and should just contain the data we've loaded (ideally with cache timeouts). We should do pagination as-usual, only fetching the data we want to display immediately, but saving any data for fast page transitions.
When offline mode is enabled, the local DB should be stored in IndexedDB. There should be a configurable storage (default=100MB) and time (default=30 days) limit for how long we will keep entries. There should also be a separate limit for read entries (default=2 days). We should pre-cache all tags and subscriptions in offline mode, along with the entries matching the configuration.
If we hit the storage limit we should delete the oldest articles from the cache until we're at the limit (we should try to do this in one query - lookup how many entries we would need to delete from the cache and then delete them all at once).
I think the best way to do this is with Tanstack DB: https://tanstack.com/db/latest
This should let us define fetching logic and automatically use the local DB first while fetching additional data in the background. We will need some translations between our cursors and Tanstack DB's offsets (we will likely need to store a cursor per list we're paginating).
Our unread entry logic is very complicated, and we can't do the easy thing here (calculating unread from DB counts) because we won't necessarily have all of the entries or subscriptions cached. To handle this, we should store the counts from the server for each list (All, Saved, Starred, each tag, each subscription), and a local delta based on our changes to the read counts.
We will likely need a persistent update queue (also Tanstack DB?), so we can keep track of updates we need to apply to the server and restart them when we're online. We can add to the update queue in our optimistic update logic and remove from it when the mutation completes? Then we should be able to calculate deltas dynamically by reading the queue.
Cache update logic is complex, so we need 100% of reads to use Tanstack DB when appropriate (tags, subscriptions, entries, counts) and to not mix Tanstack DB and direct usage of React Query.
Tanstack DB only runs client-side so we'll need to hydrate via SSR but not actually render until the client side.