Working through an interesting data design thought...

# compose

[Garret Yoder]

Working through an interesting data design thought experiment in my head.

What do you guys think the best structure would be to give the UI a cached item now that may (or may not) update with a live item later?

eg; pass the UI a MutableStateList that contains the immediate cached data, and then a second or two later begin swapping items with the now downloaded live data.

I was almost thinking something like a list of Flows? where the first is the cached copy and then the second is the fresh one. That seems really heavy and overkill though.

(This is multiplat - so I can't rely on anything android)

[Ian Lake]

Sounds like the exact kind of problem statement Store was designed to solve: https://github.com/MobileNativeFoundation/Store

[Garret Yoder]

I've been tinkering with Store this morning actually, but I didn't think it had an explicit method to push cache then live? It'd still just push cache if available

[Pablichjenkov]

Normally what I do in my usecase, I check for cache data and if it is valid according to specific rules just return it. If invalid then set the loader state and the fetch the data from network.
I have seen patterns like the one you mentioned but it turns out that if the network request is fast the screen flashes, same with always returning a loader. That is why I found better not to show a loader if the data is locally cached

[Garret Yoder]

Oh I wasn't going to show a loader - I was just going to instantly load the cached data and then replace it with the live data later

[Garret Yoder]

the only things that would change would be attributes like a comment count for example

[Ian Lake]

Store automatically pushes cache then live, that's why they let you control the in-memory cache: https://mobilenativefoundation.github.io/Store/store/store/#configuring-in-memory-cache

That whole doc goes through quite a bit of the combinations you might want (in-memory cache, disk cache, local databases, network, etc.)

[Garret Yoder]

Right, but that would just pop the memory cache before it ended up re-loading from disk (or net if disk does not exist).

But I don't see any documentation on how you'd configure it to provide cache but then re-validate the data against the net every time, or how you'd get a notificiation that new data from the net has arrived and the cache (be it memory or disk) is now stale

[Garret Yoder]

I'm not making a reddit app since the API is toast now, but take a reddit app as a good example.

I'd want to display the post list based on the cache I already had of each post, and then go grab fresh info about each post from the network. A second or two later when the results came down the user would just see something like the upvote or comment count on a given post silently update.

I suppose I could just have a flow that emits the fresh data, and then find each item in the mutablestatelist by ID and then replace it - but again that seems heavy

[Ian Lake]

That's exactly what Store does for you

[Ian Lake]

Gives you a flow of data that can come from cache or local or network and it doesn't matter to your UI, since Store is swapping them out to give you the freshest data

[Pablichjenkov]

I see, as long as the transition is not too abrupt then it shouldn't cause flashes. Something like updating text and colors should be ok I guess.

[Garret Yoder]

I see. So a given stream call can emit the same item key ID multiple times where it could first grab cache, and then in the background a net request is made based on the Fetcher to which it could emit the same key id later with fresh data

[Garret Yoder]

And you'd just have to keep the end resulting state list unique by the same key ID

[Zoltan Demant]

Maybe Im missing the point, but wouldnt you get the desired behavior simply by having a single SOT? Then it "doesnt matter" how your data comes through or where it comes from - when the SOT updates, your UI reflects the data.