https://kotlinlang.org logo
#arrow
Title
# arrow
c

carbaj0

11/15/2023, 7:38 AM
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.
https://github.com/carbaj03/WeatherApp.git branch optics if you want to see the full code
a

Alejandro Serrano.Mena

11/15/2023, 8:47 AM
interesting... your
Store
really reminds me of fritz2's approach, which also focuses on a single flow
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?
👍🏻 1
s

simon.vergauwen

11/15/2023, 9:40 AM
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.
a

Alejandro Serrano.Mena

11/15/2023, 2:36 PM
I've turned some of your utilities into a PR for Arrow https://github.com/arrow-kt/arrow/pull/3299
👍 1
I think the
Store
is too opinionated at this point to be included in the main library, but several utilities could really help
2
c

carbaj0

11/15/2023, 4:41 PM
❤️ I’m glad to know that you found it useful or inspiring.
🥰 2
s

Stylianos Gakis

11/17/2023, 11:46 AM
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
Copy code
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:
Copy code
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?
a

Alejandro Serrano.Mena

11/17/2023, 2:00 PM
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
s

Stylianos Gakis

11/17/2023, 2:04 PM
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.
3 Views