I have set up my app using clean architecture. The...

# mvikotlin

[tieskedh]

I have set up my app using clean architecture.
Thereby, I have UseCase-classes which have an Input and transform it in an Output-flow or a single value.
I want to hook this up with this framework.

MVIKotlin should only know about the state of the application.
I think the executor should therefor make decisions to start/stop a Use-case? I think using a sealed class Task which the binder then connects to the real use-cases is the best way?
The output of the use-cases should then be dispatched to the reducer.
Probably using the binder too?
Intents that only need simple updates (which don't need suspending) can be dispatched by the Executor itself.
The other alternative would be to give the Use-case classes all to the executor (which is a SuspendingExecutor after all), but I think this approach is way cleaner.

The Task-class could be implemented using Label with a lambda to dispatch.

Is this the way to go, or is there a better one?

[Arkadii Ivanov]

I never used Clean Architecture with MVI. From my point of view you can do the following. Pass use cases to the MVIKotlin Store. Then you can observe them permanently in the Bootstrapper. Intents can be processed by the Executor, which can call use cases as well. All results sohuld go to the Reducer as Results.

[Arkadii Ivanov]

Alternatively, you can keep some use cases separate, and just bind their outputs to the Store input (Intents).

[tieskedh]

Thanks!
One little question, if I would bind it using the Binder (somehow), it would come across the logging-middleware which I would miss if I'm calling straight away, isn't it?

[Arkadii Ivanov]

Binders are normally used outside of Stores. So you can bind any data to Store Intents. All intents will be logged.

[tieskedh]

To recap:
Ok, so basically I'm creating a supervisor-executor which can start/stop/command other external UseCases (kind of executors).
Therefor it can send a sealed class Task (Label) with the correct data.
The results of course need to go back to the Reducer.

I can move those UseCases to the Bootstrepper.
There I can observe them and send results as action to the Executor, which links them to the Reducer.
The executor can send data to them using Labels.
In that way, everything is picked up by the middleware?

[Arkadii Ivanov]

Your Executor and Bootstrapper can both depend on Use Cases. Bootstrapper can observe Use Cases and send data as Actions to the Executor. The Executor can produce Results, which are handled by the Reducer. The Executor can also talk to Use Cases to do some additional actions. Intents, Actions, Results (and also Labels if any) are all automatically logged.

[tieskedh]

Thank you very much!

[Arkadii Ivanov]

Feel free to ask any questions!