IssueTracker

Problem

Currently, Paging flows are collected through collectAsLazyPagingItems. The API does not provide a way to specify which coroutine context to use, that leads to collecting the flow on the main thread.

the transformation happening on the flow (e.g. pagingData.map can be costly and would add up), ideally host app should be able to specify where that runs.

right now, the Java api allows to specify an Executor. I believe the same cannot be achieved through the kotlin overload:

1. Wrapping pagingData.map with a context does not propagate (pseudocode):

      .flow
      .map { pagingData ->
        withContext(coroutineContext) {
          // in coroutineContext
          pagingData.map { item -> 
                           // back to main thread
                           foo(item)
          }
        }
      }
      .cachedIn(viewModelScope)

Note that it would be the same behavior if flowOn was used to specify another coroutineContext. pagingData.map would still execute on main thread.

2. Wrapping inside pagingData.map works but results in some overhead for each item:

      .flow
      .map { pagingData ->
        pagingData.map { item ->
          withContext(coroutineContext) { foo(item) }
        }
      }
      .cachedIn(viewModelScope)

Proposal

collectAsLazyPagingItems should take an optional coroutine context and use it like:

public fun <T : Any> Flow<PagingData<T>>.collectAsLazyPagingItems(
  coroutineContext: CoroutineContext = EmptyCoroutineContext
): LazyPagingItems<T> {
  val lazyPagingItems = remember(this) { LazyPagingItems(this) }

  LaunchedEffect(lazyPagingItems) { withContext(coroutineContext) { lazyPagingItems.collectPagingData() } }
  LaunchedEffect(lazyPagingItems) { withContext(coroutineContext) { lazyPagingItems.collectLoadState() } }

  return lazyPagingItems
}

Where the default value for coroutineContext should be backward compatible with current behavior.