Why does

.map

on a

StateFlow

returns a

Flow

?

because

.map

defined as extension to

Flow

?

Fair enough, but why? what If I want to

.map

a StateFlow and still keep it a StateFlow

Write your own

map

that creates new instance of

StateFlow

and return it explicitly

Defenitely, thanks for replying btw.. this is what I’m doing

You should return

Flow

from these functions

I could, but the client the needs to use it like this

viewModel.observeBarEvents.collectAsState(initial = ???)

because state flow has initial value )

Exactly, that’s why I want to keep it a StateFlow

However you doesn’t need state flow in UI, because UI might emit the value to state flow

would it? … it’s not a MutableStateFlow

Hm. Maybe you’re correct. But i’d find a way to pass initial value from view model

let me see… What is

value

in this case?

value is initial value in stateflow. Is it accessible?

what is the

...

in

val sf : StateFlow = ...

?

map

returns a

Flow

no matter what because its lambda can suspend. The best it could statically do, unless you can have non suspending lambda overloads, is return a

SharedFlow

.

that, plus there's a whole lot of implications of keeping each intermediate value along a chain of observable value holders

@iamthevoid

value

is accessible! but

collectAsState

is only available on a

Composable

context @Adam Powell

…

is a

MutableStateFlow

in deed. Will explore using SnapShotstate instead

You can add

@Composable

annotation to your function🤷

True! that would work… but the mapping needs to happen in the View (composable)

You can do it inside vm, example

if the source of the data is a

MutableStateFlow

then using snapshot state instead this simplifies to:

class MainViewModel {
    var source by mutableStateOf(...)
        private set 
    val isFoo: Boolean get() = source is Foo
    val isBar: Boolean get() = source is Bar
}

any reads of

isFoo

or

isBar

are observable. Instead of using

collectAsState

you can just write

vm.isFoo

without any special collect calls or mapping operators

@iamthevoid Could, work, the view is still too smart for my taste (knows which mapper to use). Also there’s a lot of back and forth. I’d like the view to just hook up to the VM and start listening. @Adam Powell exploring usiing

mutableStateOf

instead will see how it goes

cc @Manuel Vivo for general topic interest 🙂

uhm

mutableStateOf

won’t cut it for me either (I think) The example I show above is not actually what I’m doing, this is what I’m actually doing

class MainVm {
  
   val stateFlow = ...

   val fooHandler = FooHandler(stateFlow.map { it is Foo })
   val batHandler = BarHandler(stateFlow.map { it is Bar })
}

can you post the code for FooHandler/BarHandler?

not sure it’ll help but here it is (this is BarHandler)

I don't see the mappings, is that what you're trying to move into the viewmodel class?

I see

updated the gist*

try:

open class SliderContextualViewModel(
    private val getFilters: () -> Map<FILTER, FloatArray>,
    val onFilterChanged: (FILTER, FloatArray) -> Unit,
    val onFilterCommitted: () -> Unit = {}
) {
    val filters: Map<FILTER, FloatArray>
        get() = getFilters()
}

then use it like

// note: mutableStateMapOf is a snapshot state map
private var appliedFilters = mutableStateMapOf<FILTER, FloatArray>()

val lightContextualViewModel = SliderContextualViewModel(
    onFilterChanged = ::onValueChanged,
    getFilters = { appliedFilters.filterKeys { listOf(FILTER.EXPOSURE, FILTER.GRAIN, FILTER.VIBRANCE).contains(it) } },
    onFilterCommitted = history::onCommit
)

I just checked the Compose Architecture doc and we should show more code in general. In particular, I think we should show a ViewModel-like class that holds the UI state using

mutableStateOf

instead of `StateFlow`/`LiveData`. If you’re not working on a hybrid screen, using the latter makes no sense to me 🙂

@Adam Powell worked first try 😛arty-parrot:

@Zach Klippenstein (he/him) [MOD] did a really approachable writeup on it: https://dev.to/zachklipp/introduction-to-the-compose-snapshot-system-19cn

ViewModel-like class that holds the UI state using 

mutableStateOf

 instead of `StateFlow`/`LiveData`. If you’re not working on a hybrid screen, using the latter makes no sense to me

@Manuel Vivo what do you mean by hybrid in this context?

Meant the case of a screen that uses both Compose and the Android View system. As you could be in a migration phase, you’d likely have a AAC ViewModel class that is in charge of handling the View logic and usually exposes a stream of UI state using

StateFlow

or

LiveData

. So if you’re mixing both approaches, you could also consume that stream for Compose. But if you’re in a Compose-only screen, you could just use the Compose State APIs.

Gotcha, makes sense thanks!