`MutableStateFlow` is great for passing around a shared cache, or is it? :thinking_face:

# coroutines

[Marc Knaup]

MutableStateFlow is great for passing around a shared cache, or is it? 🤔

[louiscad]

Beware of race conditions on update, but yes.

[Marc Knaup]

Oh, wait. That way if I update the cache I immediately receive the update myself again.
That’s not good 😅

[louiscad]

Better to wrap the cache in a domain specific API

[Marc Knaup]

Makes sense

[Marc Knaup]

I still have a cycle.
Whenever I save to the cache I also receive the same value as an update.

I will need some logic so that whoever updates the cache doesn’t receive the same value back 🤔

[Marc Knaup]

Maybe something crazy like:

fun <T> MutableStateFlow<T>.withoutEmittingValueChanges(): MutableStateFlow<T> = …

It returns a new MutableStateFlow that only emits values if they were not set by that Flow itself.

[Casey Brooks]

I woudln’t say it’s necessarily an issue that whoever sets a value also gets an updates; it helps ensure that the UI is actually reacting to changes in that cache rather than making ad-hoc updates on its own.

[Marc Knaup]

It is if it’s recursive.

My flow:
1. Collect data from cache
2. On cache data change, start updating data from API using the cached data as initial data
3. Send new data to cache

That’s an endless loop

[Marc Knaup]

No UI here

[Marc Knaup]

The problem is that the emission of values that will be cached depends on initial value supplied by the same cache

[Marc Knaup]

Here’s my actual code that would now have that problem

[Marc Knaup]

I’ve posted in the wrong channel.
Solution I’m working on: https://gist.github.com/fluidsonic/a06419b1c129f3045558c63cbafecca4