Is it recommended to use LaunchEffect to observe U...

# compose-wear

[Jonathan]

Is it recommended to use LaunchEffect to observe UI state changes. For example if I wanted to updated my viewModel with the currently selected item from a Picker(…) would it be recommended to use the following:

val pickerState = rememberPickerState(initialNumberOfOptions = 10)
LaunchedEffect(key1 = pickerState.selectedOption) {
    viewModel.onItemSelected(pickerState.selectedOption)
}

If not, what is the recommended pattern? I would like to update my viewModel with the current UI state.

[Chrimaeon]

I’d rather use a snapshotFlow inside the LaunchedEffect
https://developer.android.com/jetpack/compose/side-effects

[Jonathan]

This is exactly what I need. Only bummer, updating the initially initiallySelectedOption of rememberPickerState(…) causes a janky scroll. Debounces does help but since a new snapShotFlow gets created collect lambda will get invoked twice. Either way I will design around this. Thanks for the brilliant suggestion.

[Chrimaeon]

Why would the snapshot be recreated? You only set the state as key and not the option itself, right?
Also try setting the initial value before the LaunchedEffect.

[Jonathan]

I’m setting the PickerState as the key but if set the value of initiallySelectedOption to state maintained by my ViewModel (similar to how you would keep a Switch up to date with your vm) it’ll create a new picker state.

[Chrimaeon]

Then you should rethink what your architecture . Setting a new state via the viemodel should not trigger the picker to be recreated.

[Jonathan]

How else would you keep your picker in sync with your ViewModel? Such that you can update the selected value in the ViewModel?

[Chrimaeon]

Either use the picker state as state or your viemodel is the state. Choose one 😏

[Jonathan]

I have to use a picker state. I don’t have a choice not to.

[Chrimaeon]

You should ask yourself - why has the viemodel need to know the selected option?

[Jonathan]

I don’t really understand your question. I use the viewModel to contain state that I present in the UI such as the currently selected picker value. If some other state changes, the selected picker item should be changed correspondingly because the currently selected value may no longer be valid etc.

[Chrimaeon]

No, the view model should not be responsible for the cuurently selected value, the picker state is. That‘a what I mean with rethink your archetictur. When you use a picker state you have 2 state holder with different responsibilities.

[Chrimaeon]

I think you mix up state and events.

[Chrimaeon]

Anyway, just giving hints without knowing your real use case and code base. 😊 good luck with it 👍🏻

[Jonathan]

I would like to show a selected value in a picker based on data from my viewmodel. If the the picker selected value changes, I would like to inform my viewmodel to perform validation and update other UI related state. I would also like the ability to inform the picker to select a new item if the other UI related state changes.

[Jonathan]

Should I expose a stateflow in my viewmodel that I would collect in my UI to manually update the pickerState via scrollToOption(…)?