I'm showing a list of named gadgets. They have a s...

# compose

[Travis Griggs]

I'm showing a list of named gadgets. They have a simple MutableState<String> name property. I fetch the list of a gadgets from a "Repository". The names are update-able (that's why I made them observable). So if the name changes, my "row" automagically updates. Isn't compose just beautiful?

Where it's a bit complicated (for me) is that I want to sort the list by that name. If my app was the only one that could change the name, then it wouldn't be too bad. As a side effect of changing the name, I could some trigger a recomposition at the Column level. But it's a multi user system. So the update to the name field could come asynchronously. I don't want the repository to keep track of "sorting" the gadgets, because it's just a keyed map basically. Is there an idiomatic way to solve this sort of problem?

[Pablichjenkov]

Not sure if I properly understand but basically what you need is to consume a hot flow. Expose a StateFlow from your State and consume it from the composable.

[Travis Griggs]

Why do I need to consume a "hot flow" ? I don't even know what that is really 🙂 I'm a little confused (honestly and humbly) how you can know that's what I need to do if you're stating up front "...not sure I properly understand..." But I'm trying to have an open mind here...

[Pablichjenkov]

Look for hot stream vs cold stream or hot flow vs cold flow. Is basically the way you work with the pipeline. A pipeline is made out of Chain multiple flows. Now a cold pipeline is started or start processing, once the collector/consumer endpoint pull down the events.
However, a hot pipeline is always sending messages down. It doesn't care if a consumer is connected or not. it starts sending events down as soon as the server or sender endpoint gets started

[Pablichjenkov]

That's speaking in a general stream way. Down to kotlin coroutine, the cold flow processing starts when flow.collect is called in a coroutine scope. Usually the cold stream is only process by one scope.
In the case of the hot one, there is 2 scopes involved the sender and the listener. Even if you cancel the listener scope, the producer scope keeps alive sending events

[Pablichjenkov]

If you want to learn more look for reactive streams theory, or message driven system design or reactive manifesto rules or reactive system design rules. There is a whole world around that

[Travis Griggs]

This all sounds good -- and I appreciate you taking the time to explain it in these broad strokes. That you're an advocate is pretty clear.

I think my question can be abstracted as:
• Given an sized Set of observable things, with 1:1 ties observable things and consumers
• There can be a need to additionally observe/consume the set of all changes of that type at a single consumer level, rather than the individual changes themselves
Does the flow stuff help me with that? I was rather enjoying the flexibility of just simple MutableStates 😕

[Pablichjenkov]

I thought that you were listening for message events coming from a socket or some sort of hot source, lol. And then you wanted that event to reach the composable column with some processing in between. That's why I talked about the flow stuff. But now I see, basically what you talk about, is structuring state. In such a case I would say it is up to you the way you design it and expose it to the consumer.
Flows help with event processing because it has an army of operators. Compose State is not, so you have to do whatever event processing on your own. Which sometimes turns out to be simpler.