Tin Tran
07/28/2022, 4:34 AMModalBottomSheetState
to ViewModel?oianmol
07/28/2022, 5:14 AMTin Tran
07/28/2022, 6:06 AMLaunchedEffect(key1 = state.showBottomSheet) {
if (state.showBottomSheet) {
bottomSheetState.animateTo(ModalBottomSheetValue.Expanded)
} else {
bottomSheetState.animateTo(ModalBottomSheetValue.Hidden)
}
}
But if the user touch the scrim or swipe the bottom sheet down i’ll have to do this to notify the VM which I think is kind of cumbersome
val bottomSheetState = rememberModalBottomSheetState(
initialValue = ModalBottomSheetValue.Hidden,
confirmStateChange = {
if (!state.bottomSheetCancelable) {
return@rememberModalBottomSheetState false
}
if (it == ModalBottomSheetValue.Hidden) {
Timber.d("test test test")
keyboardController?.hide()
viewModel.reduce(LoginEvent.HideBottomSheet)
}
true
}
)
Albert Chang
07/28/2022, 10:22 AMModalBottomSheetState
is a UI state.oianmol
07/28/2022, 10:39 AMAlbert Chang
07/28/2022, 10:51 AMthe bottomSheetState which is also a composableNo,
ModalBottomSheetState
is not a composable. It’s a UI state class.
If in future you would want to move away from Bottom sheet’s you would end up refactoring viewModelsWhat’s the problem of refactoring view models? Do you design your view model so that any future UI change doesn’t need any modification of view model? Is that possible anyway? Creating this kind of unnecessary restriction for yourself only makes your code more verbose and more complicated. We usually call this over-engineering.
oianmol
07/28/2022, 10:54 AMAlbert Chang
07/28/2022, 10:56 AMModalBottomSheetState
instead of rememberModalBottomSheetState()
😄oianmol
07/28/2022, 11:02 AMModalBottomSheetState
for you! So what you essentially passed to your VM will not be the same instance. Does that make sense ? lmk if something is not clear or if I am wrong?oianmol
07/28/2022, 11:05 AMModalBottomSheetState
will be different after config change. that's why you should not pass it to your VM. It's an anti pattern. We are repeating the same mistakes again, it's like passing Activities to your AsyncTasks! 🤦Albert Chang
07/28/2022, 11:06 AMModalBottomSheetState
has a public constructor which you can directly use to initialize the class in the view model.oianmol
07/28/2022, 11:08 AMrememberModalBottomSheetState()
and take care of config changes with rememberSaveable ?oianmol
07/28/2022, 11:09 AMAlbert Chang
07/28/2022, 11:11 AMModalBottomSheetState
as a member of view model and the view model survives configuration changes?oianmol
07/28/2022, 11:40 AMModalBottomSheetState
and use in the VM, but by moving it there you give your VM the responsibility to deal with UI interactions, for me I think of it as if I am writing click listeners within the VM, but you are right we just end up calling expand
and hide
so it works. I am just thinking out loud, if I follow what you are mentioning here would it lead to memory leaks or some unexpected behaviour 🤷fengdai
07/28/2022, 1:06 PMfengdai
07/28/2022, 1:15 PMSimple state hoisting can be managed in the composable functions itself. However, if the amount of state to keep track of increases, or the logic to perform in composable functions arises, it’s a good practice to delegate the logic and state responsibilities to other classes: state holders.&
a ViewModel is a special type of state holder
Colton Idle
07/29/2022, 4:14 AMjossiwolf
07/29/2022, 9:01 AMrememberModalBottomSheetState
means that you get saving for free, yes. But it's perfectly fine for the state to live in the VM as part of your UI state🙂 Follow the same state saving best practices for that as with the rest of your UI state.Tin Tran
07/29/2022, 9:37 AMManuel Vivo
08/01/2022, 9:10 AMrememberMBSS
saves the state across process and activity recreation. If you hoist it in the VM, you’d need to handle that yourself using the SavedStateHandle