This feels like a great fit for a normalized, index-driven state model — keeping media entities separate from date/year indexes, so views can be composed cheaply without duplicating data. Especially useful when the same asset appears across multiple date-based views.

Yes — that’s exactly the mental model.

Media assets are treated as immutable entities, and all the date-based navigation is built on top of lightweight indexes derived from capture timestamps (day/month/year). That way the same asset can appear across multiple views without duplication or recomputation.

It also keeps memory usage predictable when dealing with large libraries, since views are essentially projections rather than separate collections.

The main constraint is that everything has to stay fast and incremental, because it’s all happening on-device with no background preprocessing or server-side help.

Curious if you’ve used a similar approach elsewhere — it felt like the simplest way to keep things both flexible and cheap

Thanks, appreciate the link.

I’m mostly interested in the architectural side rather than a specific tool: how people separate domain state from transport, where optimistic state lives, and how retry / reconciliation is usually modeled without leaking everywhere.

Still useful to see how existing systems approach client IDs though.

Cool, makes sense. We still want to write a blog post about how we built powersync that will go into more detail on the points you raised.

The one thing I'll add is we found "keeping UI responsive while syncing in the background" is highly platform dependent since all platforms have their quirks, but for React Native we have a detailed blog post and code (admittedly tightly coupled to powersync, but should provide a starting point) https://www.powersync.com/blog/keep-background-apps-fresh-wi...