I have an “idea for curious Kotliners” :stuck_out_...

# arrow

[carbaj0]

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.

[carbaj0]

https://gist.github.com/carbaj03/2c178f023e29d4d29df71f15c44b15e1

[carbaj0]

https://github.com/carbaj03/WeatherApp.git branch optics if you want to see the full code

[Alejandro Serrano.Mena]

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

[Alejandro Serrano.Mena]

I'm thinking that maybe having a copy version working directly on a MutableFlow / MutableState could be very useful when working with Compose, isn't it?

[simon.vergauwen]

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.

[Alejandro Serrano.Mena]

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

[Alejandro Serrano.Mena]

I think the Store is too opinionated at this point to be included in the main library, but several utilities could really help

[carbaj0]

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

[Stylianos Gakis]

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?

[Alejandro Serrano.Mena]

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

[Stylianos Gakis]

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.