One Off the Slack: CoroutineScopes and Compositions

Florian Schuster asked:

Hey, I need a CoroutineScope that lives as long as the current composition.

Google’s Adam Powell pointed out an upcoming launchInCompose() option, for this, though it is still incubating. The key is the onCommit event of a composition, because as Adam notes:

Composition is transactional; it can happen speculatively and it can fail. By performing side effects only in onCommit-like constructs you can avoid having to detect these situations and attempt to roll back.

Today there aren’t many situations where this happens, but we’re in the process of setting things up so that composition can occur off the main thread. We’ll be able to allow large recompositions that spend a lot of time in app code to span multiple frames, while the existing app UI can still continue animating by whatever mechanism, etc.

This will also allow all sorts of background prefetching of content in recyclerview-like scenarios

(and pre-fetching seems seriously cool)

The thread then dives into a discussion between Adam Powell and Arrow’s Raul Raja about the similarities and differences between suspend functions and @Composable functions, in terms of how they wind up being implemented by Kotlin (and, in the case of @Composable, by the Compose compiler plugin).

Adam and Florian then continued to review Florian’s scenario, for which launchInCompose() did not appear to be a solution. This is in support of Florian’s control library, an MVI-style unidirectional data flow engine, powered by coroutines, that Florian is attempting to adapt to Compose.

---

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!