doubov
05/09/2022, 4:22 PMArkadii Ivanov
05/09/2022, 4:49 PMActions
, that are handled separately in the Executor
. This makes the Executor
implementation more deterministic and readable. It also allows Actions
logging and time-traveling.
You can use Intents if you like. There are no strict rules here.doubov
05/09/2022, 5:00 PMSet<Intent>
as a constructor argument on the Executor
(which would keep this an internal implementation detail as well).
I'm asking because we are currently using our own mvi framework that isn't KMP ready and thinking of proposing that we use MVIKotlin for viewmodels in KMP and trying to understand the use-cases for `Action`s. We currently have a Set<Intent>
as a constructor param on the ViewModel/Store
that get passed to Executor
and it seems to work wellArkadii Ivanov
05/09/2022, 5:06 PMIntent.Init
, which is the public API of the store. So the store will use its own public API, which is not quite clean from the code perspective. And also you are technically able to send Intent.Init
from outside, which kinda goes against the encapsulation.
• In the Bootstrapper
you can do async jobs. E.g. you are able to subscribe to network or database events, and emit an Action
for every such event. The Executor
will handle each such emission separately. Each such Action
can be logged, and time-traveled if desired.doubov
05/09/2022, 5:26 PMIntent.Init
cannot be called multiple times. We do currently have to handle this logic manually to ensure that Intent
doesn't get called multiple times.
I'm not sure if the added complexity is worth it for us. It's great that MVIKotlin is flexible and the Bootstrapper
is optional! Thanks for the explanation and writing this awesome library!Arkadii Ivanov
05/09/2022, 5:29 PMdoubov
05/09/2022, 5:31 PM