I have an “idea for curious Kotliners” 😜 based on the WheaterApp example. I use optics as a mechanism to manage the global state of the app.

interesting... your

Store

really reminds me of fritz2's approach, which also focuses on a single flow

Yes, I'd say so. Something that does

update

+

copy

out of the box could be very interesting. I am also a big fan of single flow for UI state.

I've turned some of your utilities into a PR for Arrow https://github.com/arrow-kt/arrow/pull/3299

❤️ I’m glad to know that you found it useful or inspiring.

I have some questions regarding the functions that are defined as extensions on

MutableStateFlow

. On Android at least, I’ve opted to basically completely stop using this pattern

private val _state = MutableStateFlow(…)
val state = _state.asStateFlow()

to handle screen state, as this more often than not means that you are then creating some hot state that lives for the entire time that the state holder lives for, and does not care for if there are any consumers at the time or not. So this means that if you are listening to any cold flow, you’re turning it hot and are listening to it, even if there may be nobody listening on the values that it produces. Instead, it’s always better to define a bunch of cold flows for data transformations etc. and then combine them all together in a chain like:

combine(flow1, flow2) { _, _ -> ...}
  .stateIn(...)

To get the final

StateFlow

which is going to be public API of the state holder class. So this means that I never end up having a

MutableStateFlow

instance to use those extension functions for. Is this something that you folks still end up using? Is this too much of an Android concern perhaps?

you should still be able to apply an optic to a

StateFlow

(here's the code -> https://github.com/arrow-kt/arrow/pull/3299/files#diff-5488443062b3bef62e232724eda7af102bb35ee694caf248a8e220d6781561f9R23) what you don't get, though, is the ability to apply a

Lens

(only a

Getter

) because you cannot mutate it. In other words, since your

state

is just a

StateFlow

, you can only view more specific information, but not change it

Right, but my thought there was that you don’t want to do that anyway. If you are in a situation with a

stateIn()

, you can just call another

Flow.map {}

and use normal lenses to change some part of the state you got at that point, right before the last

stateIn

call which turns your flow into the

StateFlow

that you need.