View and Binder with compose

[manosbatsis]

I was wondering if there's any sample that applies, if at all possible, MVIKotlin Binders and Views (or equivalent!) to a stack like the one used in the TODO App, i.e. store > component > (compose) content.

[arkivanov]

I haven't seen any such examples, but usually there is no need to use Binder and MviView with Compose UI.

Binder is just for automatic subscription management. Compose is able to subscribe on its own using State. You also don't need diff, because Compose does this automatically. UI events could be just send using normal functions, e.g. you just call a method on your component, like component.onBackClicked().

MviView also seems redundant in usual scenarious, when you only use declarative UI frameworks. You just write your Composable functions (or SwitUI views, or React components), and the UI just observes the exposed state.

However, there are some use cases. E.g. both Binder and MviView could be useful if you have mixed declarative and imperative UI (e.g. on different platforms). In this case you will do something like this:

interface SomeView : MviView<Model, Event> {
    data class Model(val text: String = "")

    sealed interface Event {
        object OnButtonClick : Event
    }
}

class SomeViewImpl : BaseMviView<Model, Event>(), SomeView {
    private var model by mutableStateOf(Model())

    @Composable
    fun Content() {
        Button(onClick = { dispatch(Event.OnButtonClick) }) {
            Text(model.text)
        }
    }

    override fun render(model: Model) {
        super.render(model)
        this.model = model
    }
}

[manosbatsis]

True, true. I was more interested in subscribing components (e.g. TodoEditComponent) to state and label flow updates from the store. I typically do something like this in my components:

override val model: Flow<MyComponent.Model> = store.states.map { /*...*/}

but the equivalent doesn't seem to work for labels. Would serve well for e.g. signaling "persistence finished" or whatnot. Also i had the feeling i might be missing a better approach to trigger events from the UI > component chain than calling component.fooIntent or component.handle(intent) and then store.accept(intent)

[arkivanov]

To subscribe for state updates and labels, you can either use Binder as usual (it's unrelated to Compose), or you can use a CoroutineScope (see Scoping jobs and subscriptions).

Re: better approach to trigger events

As you mentioned, that's just one method in a component - component.handle(intent). This doesn't look like a big overhead. However, since you are sending Intents directly from UI, you can reduce the boilerplate a bit.

class ListComponent(
    private val storeFactory: StoreFactory,
) {

    private val listStore: ListStore = ...
    val handle: (Intent) -> Unit = listStore::accept