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
for this, though it is still incubating. The key is the
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
@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.