I have this in my composable screen, but ideally I'd like to control this state from my vm. Is that ...

# compose

[Colton Idle]

I have this in my composable screen, but ideally I'd like to control this state from my vm. Is that frowned upon or is it normal to move these remember*State calls to my VM?

Example:

val bottomSheetScaffoldState = rememberBottomSheetScaffoldState(bottomSheetState = BottomSheetState(BottomSheetValue.Collapsed))

[Filip Wiesner]

Well, you can't move remember*State calls to VM because they are usually Composable.

[Filip Wiesner]

If there is some underlying public state you can instantiate than you can probably move that but I am not sure how bad/good practice that is. I never really thought about that

[Colton Idle]

Yeah. To give more color on my situation.

I have a regular dialog.

Composable screen contains:

if (viewModel.state.showModal) {
        Dialog(onDismissRequest = { viewModel.state.showModal = false }) {
          Box(Modifier.size(dialogWidth, dialogHeight).background(Color.White)){
                Text("Modal")
            }
        }
    }

and the VM is a simple:

var showModal by mutableStateOf(false)

but now my designer wants a bottom sheet, and idk how to model my bottom sheet in my VM.

[Francesc]

I would just point out that I would not allow the view to mutate the state,

viewModel.state.showModal = false

call a method in your viewmodel to do so. There should be just 1 source of truth (the viewmodel), by allowing the view to mutate the state you have 2

[Francesc]

and the method in the viewmodel should be something like onDialogDismissed and not something like resetShowModal because the view should be agnostic of what happens on dismissal, just that it needs to communicate that

[Colton Idle]

Thanks for the tips, but I just want to point out that it doesn't address my question, so if anyone knows what the best way to go about shifting this state into the VM from a composable that would be awesome.

[Francesc]

well, the first thing you should ask yourself is whether this is something that the viewmodel should be responsible for. In my opinion, it is OK to have things like the scroll state handled at the composable if it is used solely in that composable. Another option is to have a state holder instead of moving this to the viewmodel, it all depends on the scope in which that state is used