Hi everyone. Is it normal to use labels to do something in the view (like navigation for example) ? from the scheme it is not right. but sometimes we can’t use the state for it.

Hello! Labels were introduced exactly for such cases. They are one time events. Just be careful, you can't do navigation in background, and Labels can be missed in this case.

Great, thx

I'm currently attempting to build out a coordinator pattern that maps the relevant labels to coordinator events -- a lot of iOS apps already use this pattern for navigation and I see quite a bit of reuse between the platforms being available. The coordinator relies on a navigator which is platform-specific!

Yep. This should be totally fine in iOS. There are issues with Android, e.g. you can't switch Fragments while the app is minimized. So you have to listen for Labels only while the screen is active (START-STOP). So if business logic produce a Label while in background, navigation won't happen. In such cases navigation via state is preferable. The latter can be implemented as follows (did not actually test this particular snippet, just as an example):

interface MyStore : Store<Intent, State, Nothing> {
    sealed class Intent {
        object ClearSelectedUserId : Intent()
    }

    data class State(
        val selectedUserId: String? = null
    )
}

interface Navigator {
    fun showUser(id: String)
}

class MyController(
    lifecycle: Lifecycle,
    private val navigator: Navigator
) {
    private val store: MyStore = TODO()

    init {
        bind(lifecycle, BinderLifecycleMode.START_STOP) {
            store.states.mapNotNull(State::selectedUserId).distinctUntilChanged() bindTo {
                store.accept(Intent.ClearSelectedUserId)
                navigator.showUser(it)
            }
        }
    }
}

Or there is also single-live-event pattern:

class ConsumableValue<T : Any>(
    private var value: T?
) {
    fun consume(): T? = value?.also { value = null }
}

So you don't need to clear data in state, but it can break time travel a bit in some circumstances.

Hey -- Is the ribs integration the end goal for multiplatform projects or a stepping stone to take a project written with ribs multiplatform?

Sorry @JimK could you please elaborate the question?

Sorry -- the branch in decompose project ribs-integration that was pushed up 2 days ago appears to have some tools to bridge the gap between a Multiplatform decompose project and an Android project written with the badoo/Ribs framework

Ahh yes! I'm playing with ribs-decompose interop currently. There is no intention to replace Badoo/Ribs. The Ribs framework has lots of useful Android specific features, however decompose is just a simple tool for multiplatform routing and lifecycling. But the interop would be useful if Decompose used in a Ribs based project. This would allow us to gradually introduce multiplatform features and connect them to an already existing structure.

Got it! Thanks! I saw quite a few parallels between the projects and thought maybe it was a future state for those apps (all multiplatform).

I would love if Decompose become a state of MPP apps 🙃 At the moment it is an experiment. Will probably publish a blog post soon.

MVIKotlin and decompose together appear to me to be the best out there for mpp. Moko was interesting but MVVM in multiplatform projects have proven to me to be really cumbersome to scale out.

As far as I know there is nothing about navigation in Moko, please correct me if I'm wrong. But I agree, MVI is a perfect fit for MPP.

Haha I know but compose is too cool to ignore

Absolutely

It's a necessary learning curve for future apps in my opinion. After watching the droidcon(?) video about badoo/ribs and building views depth-wise instead of breadth-wise, I figured we can burn a week or two in research / testing

Tree structure all the way!

Thanks for being active, hah!