Can/should postSideEffect be called from outside an `intent { }` block (like from a Compose button?

# orbit-mvi

[dave08]

Can/should postSideEffect be called from outside an intent { } block (like from a Compose button?

[Guilherme Delgado]

Can you elaborate?
postSideEffect and reduce can only be called inside ìntent . You can have a public fun from the ViewModel that does that

[dave08]

Yeah, I guess even side effects should pass through the viewModel/containerHost... I was thinking of calling containterHost.container.intent { postSideEffect(...) } straight from the button callback. But you're right, I don't know why I thought I saw it exist on the ContainerHost...

[Guilherme Delgado]

containerHost should be private to the ViewModel

[Guilherme Delgado]

and you should hoist everything in the compose side

[dave08]

should hoist everything

I made an interface of my ContainerHost's action functions that I pass down through the composables... or do you think it's better to have a bunch of lambdas in the function params?

[Guilherme Delgado]

@Composable
fun OverviewScreen(
    ...
    viewModel: OverviewViewModel = hiltViewModel(),
) {
    ...

    with(viewModel.state.collectAsStateWithLifecycle().value) {
                MyComposalbe(
                    ...
                    onLoadMore = { viewModel.loadMore() },
                    onDelete = { viewModel.deleteWorkOrder(it) },
                )
            }
    }
    LaunchedEffect(Unit) {
        viewModel.sideEffect.collect {
            ...
        }
    }
}

[Guilherme Delgado]

ViewModel:

[Guilherme Delgado]

fun deleteWorkOrder(id: Long) {
    containerHost.intent {
        ...
                    reduce { state.copy(...) }
                    postSideEffect( ... )
                 
                }
            }     
    }
}

[Guilherme Delgado]

an example 😊

[Guilherme Delgado]

BaseViewModel:

[Guilherme Delgado]

protected val containerHost = containerHostVisibilityWrapper<STATE, SIDE_EFFECT>(initialState, savedStateHandle) { initContainerHost() }
val state: StateFlow<STATE> = containerHost.container.stateFlow
val sideEffect: Flow<SIDE_EFFECT> = containerHost.container.sideEffectFlow

[Guilherme Delgado]

• containerHost, private to ViewModel
• state, sideEffect, public to composable

[Guilherme Delgado]

makes sense to you?

[dave08]

Yeah, you're right about hiding the the container, but it seems a bit overkill to have to hoist the actions using lambdas all the way down the hierarchy... even for testing, it's not too hard to pass a Noop fake implementation of that actions interface...

[Guilherme Delgado]

true

[dave08]

That way you avoid the onLoadMore, onDelete params, and just have:

interface Actions {
  fun onLoadMore(...)
  fun onDelete (...)
}

class ContainerHostImpl : ContainerHost..., Actions {
  override fun onLoadMore(...) = intent {...}
...
}

[Guilherme Delgado]

/**
 * Just to keep it private without public access.
 */
fun <STATE : Parcelable, SIDE_EFFECT : Any> ViewModel.containerHostVisibilityWrapper(
    initialState: STATE,
    savedStateHandle: SavedStateHandle,
    onCreate: ((state: STATE) -> Unit)? = null
) =
    object : ContainerHost<STATE, SIDE_EFFECT> {
        override val container =
            [e-mail]<STATE, SIDE_EFFECT>(initialState, savedStateHandle = savedStateHandle, onCreate = onCreate)
    }