<@UHAJKUSTU> Is there any sample with MVIKotlin + ...

# decompose

[electrolobzik]

@Arkadii Ivanov Is there any sample with MVIKotlin + Decompose + Compose? Or at least MVIKotlin + Decompose?

[Arkadii Ivanov]

Yep, there is c-c-c-combo sample: https://github.com/IlyaGulya/TodoAppDecomposeMviKotlin

Decompose + MVIKotlin + Compose + Reaktive+ SQLDelight

[electrolobzik]

Great! Thank you! I see that there are really a lot of contributors there 💪K

[Arkadii Ivanov]

Oh, I think the contributors list is a bit misleading. The sample was originally part of the compose-multiplatform repository. I created it at the very beginning, even before Compose Multiplatform became public. But recently they decided to remove all samples with third-party dependencies from their repo. And Ilya extracted the sample into his own repository. And somehow the entire list of contributors is preserved.

[Arkadii Ivanov]

Yes, I can recommend the sample.

[electrolobzik]

@Arkadii Ivanov Do I understand correctly that in this sample the decompose components have at least 2 responsibilities?
1. They provide navigation of the app parts
2. They act as a binders in terms of MVIKotlin and provide mapping between UI events and Store intents and in opposite direction from Store state to the UI state/model.

[Arkadii Ivanov]

As far as I remember, there are 3 components there. List and Details are leaf components, each contains a Store, exposes a UI model, and passes UI events back to the Store. And the Root component only handles the navigation and possibly communication between List and Details.

[Arkadii Ivanov]

There are also tests there.

[electrolobzik]

So the leaf components act as a binders, right? (https://arkivanov.github.io/MVIKotlin/binding_and_lifecycle.html)

[Arkadii Ivanov]

That's one possible responsibility. They could also have more, e.g. have nested navigation.

[Arkadii Ivanov]

They also hold the Store.

[Arkadii Ivanov]

The component interface is just a state holder and event consumer. The implementation is performed with the help of MVIKotlin.

[electrolobzik]

In the sample the root component also handles navigation and it is more like a “Store”, but used only for navigation (because it stores navigation state). I suppose if there is a more complex case with authorization (with API calls, database interactions and etc) the root component also should have a store attached to it and containing the application state instead of the component itself, right?

[Arkadii Ivanov]

That's possible, sure.

[Arkadii Ivanov]

Or you can extract a SignIn component, and act once done

[electrolobzik]

So in general the border between decompose-component and mvikotlin-store is not so precise. The component can work as a standalone thing (as a lightweight store) if it only stores the navigation state and doesn’t have any other logic besides navigation and mapping. In case there is some additional logic the store should be added and it also can or can not take navigation logic.

[Arkadii Ivanov]

There is no strong guidance here. In general, a component is just a lifecycle-aware boundary between UI and non-UI code. Everything else is implementation details.

[electrolobzik]

If I extract a SignIn component it will help with separating the logic of the sign-in process. But as I understand once finished the SignIn component will be destroyed and the part of it’s state - the authorized flag, session token etc - will not have any place to be stored except the root component, which from my point of view should not contain such elements in it’s state. Or that is ok?

[electrolobzik]

Yes, I understand that the libraries themselves don’t apply any restrictions here. But I want to understand what is the best architecture approach for this.

[Arkadii Ivanov]

The SignIn component would save the login info (token, etc) into a persistent storage, and respond to the parent with the result.

[Arkadii Ivanov]

The parent can check the storage at the creation time and initialise the stack accordingly.

[Arkadii Ivanov]

It can also install a http client interceptor and listen for unauthorized errors.

[electrolobzik]

So this bold components are fine and this logic is not supposed to be moved outside into some RootStore to avoid breaking the SRP?

[Arkadii Ivanov]

Feel free to extract the logic into separate classes, Stores etc. Depends on the component, I guess.

[electrolobzik]

Great, thanks for comments! 🙂

[electrolobzik]

@Arkadii Ivanov Where do this plugins come from? I can’t find anything in internet about them:

id("multiplatform-setup")
    id("android-setup")

[Arkadii Ivanov]

I think they are here: https://github.com/IlyaGulya/TodoAppDecomposeMviKotlin/tree/master/buildsystem/convention

[electrolobzik]

Thanks!