Send inputs on ViewModel initialization

[iruizmar]

Sometimes there's the need to launch an Input right on ViewModel init. For example, when you need to fetch some data to shown on the screen.

Checking the examples, I've seen that the way it's been done is to use the Activities onCreate, but in other architectures like a pure Compose app, using lifecycle is not really the way. Also, delegating this kind of internal actions to the view doesn't look completely correct.

Another approach I've been using is to use the init block of the ViewModel, but this is a bit cumbersome since, ideally, you will declare different ViewModels for each platform and you'll have to replicate this logic in each of them:

class MyViewModel(
    config: BallastViewModelConfiguration<MyContract.Input, MyContract.Event, MyContract.State>,
) : AndroidViewModel<MyContract.Input, MyContract.Event, MyContract.State>(config) {
    init {
        trySend(MyContract.Input.MyInput)
    }
}

My proposal is to be able to indicate a list of desired Inputs to be launched on ViewModel initialization. You can see how some other state management libraries are doing it here.

Ideally this will be set in the InputHandler since this is the class written in common code.

[cjbrooks12]

This probably doesn't need a new API for it, you can write a pretty simple Interceptor to achieve this behavior (here's the docs, something like this:

public class BootstrapInterceptor<Inputs : Any, Events : Any, State : Any>(
    private val getInitialInput: suspend () -> Inputs,
) : BallastInterceptor<Inputs, Events, State> {

    override fun BallastInterceptorScope<Inputs, Events, State>.start(notifications: Flow<BallastNotification<Inputs, Events, State>>) {
        launch(start = CoroutineStart.UNDISPATCHED) {
            // wait for the BallastNotification.ViewModelStarted to be sent
            notifications
                .filterIsInstance<BallastNotification.ViewModelStarted<Inputs, Events, State>>()
                .first()

            // generate an Input
            val initialInput = getInitialInput()

            // post the Input back to the VM
            sendToQueue(
                Queued.HandleInput(null, initialInput)
            )
        }
    }
}

You could of course adapt the behavior to wait for the initial State to be set as well, by also waiting for BallastNotification.StateChanged to be sent, or any other logic you might need for it.

I had gone back and forth on whether this is something I wanted to include directly in the core library, and while I'm definitely not opposed to having this if there's enough demand for this use-case, there are several reasons why I chose not to include it yet:

• It's easy enough to write this Interceptor yourself
• In most cases where I needed to send an initial Input, I also needed to pre-load the Input with additional values passed in via navArgs, which doesn't work as nicely with this model
• I gave myself a strict rule that I will not add any features just because they might be needed, to avoid bloating the library with unused features. As of yet, I didn't have a strong enough use case for this bootstrapper, as I was using traditional Fragment-based navigation and preferring to send the Inputs with the Fragment lifecycle rather than relying on the androidx ViewModel's lifecycle

[iruizmar]

Thanks for the deep explanation! Knowing that there's a way to do it, it works for me. Thank you :)