Why is Executor received as a Lambda, but Bootstrap and Reducer are not?

[yeldar-nurpeissov]

I’m trying to understand the behavior of the Executor in Decompose. It is received as a lambda, whereas bootstrap and reducer are not.

• Is there any specific condition that determines when an executor is created?

• I have two Intents:

  1. Collecting from a Coroutine Flow and saving the Coroutine job.
  2. Cancelling or stopping this job.

• Can I store the reference to the Job inside the executor class?

• Won’t there be a case where a new executor is created, but the job reference is stored in the previous executor, making it impossible to cancel in the new executor?

Any insights or best practices would be appreciated.

Code sample:

interface Intent {
    object DoSomeAction: Intent
    object DoAnotherAction: Intent
}

class Executor {
  private var job: Job? = null

  fun onNewIntent(intent: Intent) {
    when(intent) {
      DoSomeAction -> {
        job = scope.launch {}
      }

      DoAnotherAction -> {
        job?.cancel()
       // do something
      }
    }
  }
}

[arkivanov]

Please see the section "Creating the Store" in the docs: https://arkivanov.github.io/MVIKotlin/store.html

Why factory and not just an instance of the Executor? Because of the time travel feature. When debugging time travel events it creates separate instances of Executors when necessary and fakes their States.

Please note that executorFactory should return a new instance of the Executor every time it is called.

The following is also mentioned in that doc:

Please note that Executors are stateful and so can not be objects (singletons).

Here are the answers:

Can I store the reference to the Job inside the executor class?

Yes you can.

Won’t there be a case where a new executor is created, but the job reference is stored in the previous executor, making it impossible to cancel in the new executor?

In general, it's up to the Store implementation to decide when to create new instances of Executor. The implementations provided by the library keep the same instance of the Executor for the entire Store lifetime. The time-traveling Store implementation creates additional Executor instances for debugging, but the original instance always remains.

[yeldar-nurpeissov]

Thank you! I’ve been using Pager with Paging 3, but I noticed that whenever a page is selected or swiped, Paging 3 starts recollecting its states and briefly shows the refresh/loading state.

To avoid this, I decided to stop using collectAsLazyPagingItems(). Instead, I moved the collecting/collect of paging items inside the executor and manually recollect whenever a refresh is needed.

[arkivanov]

Thanks for the info! You can also consider to avoid using Paging 3 library. Usually with MVIKotlin you can just keep track of your paging cursor in the Store state, and just request new page on intent, and add new items to the state.

data class State(val items: List<String> = emptyList())

// In your Executor

when (intent) {
    is Intent.LoadMore -> {
        val newItems = loadMore(offset = state.items.size)
        dispatch(Msg.ItemsLoaded(newItems))
    }

// In your Reducer

when (msg) {
    is Msg.ItemsLoaded -> copy(items = items + msg.newItems)
}