flosch
05/21/2020, 6:40 PM@Composable
internal fun composeCoroutineScope(
coroutineContext: CoroutineContext = SupervisorJob() + Dispatchers.Main.immediate
): CoroutineScope {
val scope = remember { CoroutineScope(coroutineContext) }
onDispose { scope.cancel() }
return scope
}
Zach Klippenstein (he/him) [MOD]
05/21/2020, 6:52 PMCoroutineContextAmbient
that you might want to incorporate, although I’m not sure if there’s any advantage to doing so since I don’t know what it would provide other than a parent job, which you don’t care about here anyway since you’re not bubbling errors up and cancelling it yourself.Adam Powell
05/21/2020, 6:55 PMZach Klippenstein (he/him) [MOD]
05/21/2020, 7:01 PMraulraja
05/21/2020, 7:07 PMsuspend
solve those issues?Adam Powell
05/21/2020, 7:10 PMraulraja
05/21/2020, 7:26 PMflosch
05/21/2020, 7:27 PMlaunchInCompose
looks cool 👍 but it’s not really what I need.
Let’s say I have a presenter that is bound to the life of a CoroutineScope
(and also created via CoroutineScope.createPresenter
extension function) and I want to use that presenter for a Composable. Could I use the effectCoroutineScope
?raulraja
05/21/2020, 7:28 PMAdam Powell
05/21/2020, 7:32 PMraulraja
05/21/2020, 7:33 PMAdam Powell
05/21/2020, 7:33 PMraulraja
05/21/2020, 7:34 PMAdam Powell
05/21/2020, 7:35 PMraulraja
05/21/2020, 7:35 PMAdam Powell
05/21/2020, 7:41 PMsuspend
and @Composable
. There are certainly similarities, but ultimately we decided that they were different enough to keep separatesuspend
is 🙂flosch
05/21/2020, 7:51 PM@Composable
private fun AppScreen() {
MaterialTheme(colors = AppColors.currentColorPalette) {
val controller = /*coroutineScope*/.createCounterController()
val controllerState by controller.state.collectAsState()
CounterScreen(counterState = controllerState, action = controller::dispatch)
}
}
Adam Powell
05/21/2020, 7:55 PMsuspend
functions as their API surface, which ensures the caller of those functions is what brings a relevant scope alongfoo.runBar()
suspend functions that get launched from elsewhere to act as consumers or workers, which can seem a bit cumbersome until you realize that you can `try`/`catch` around those and have some very nice error reporting and recovery, rather than dealing with `SupervisorJob`s and `CoroutineExceptionHandler`s that have to put things together after the factflosch
05/21/2020, 7:57 PMAdam Powell
05/21/2020, 8:00 PMcoroutineContext
supplied as a parameter to remember
as a key param, so that if the caller changes the context for some reason, you can cancel the old scope and get a new one. That makes the onDispose
dance you're doing a bit different thoughCompositionLifecycleObserver
it will get callbacks when it enters or leaves a composition. In other words, if you remember
an object that implements that interface, compose will call its onEnter
and onLeave
methods automatically for you, and you won't need a separate onDispose
flosch
05/21/2020, 8:16 PMFor app code I probably wouldn’t worry about it, but it’s the sort of thing I would want to be very precise about if I were writing a library for wider consumptionYes, I am currently trying to figure out if using my lib with compose is possible out of the box or if I should provide a way to create a Controller for `@Composable`s without a specific
CoroutineScope
Thanks for your help though! 🙂codeslubber
05/25/2020, 8:49 PM