Is there some part in the official documentation w...
# compose
s
Is there some part in the official documentation which talks about running side-effects in composition (basically outside of one of the LaunchedEffect/SideEffect/DisposableEffect options). For example the section of “Side-effect” talks about LaunchedEffect, but as a way to run suspending functions in the scope of a composable. But I’d like to see a place which highlights why doing this in composition is wrong
Copy code
if(x) {
  callLambda()
}
and why you need to do this instead
Copy code
LaunchedEffect(x) {
  if(x) {
    callLambda()
  }
}
In order to avoid calling this lambda again and again if the composable recomposes for other reasons. Is there some part of the docs which highlights this? I can’t find any atm 👀
And the “avoid backwards writes” section talks about the specific problem of writing to state. It does kinda touch on the idea of not doing things in composition, but again it’s not the main focus of that point.
c
LaunchedEffect(x)
guarantees that no matter how many times your Composable is run, the block within your LaunchedEffect will run exactly once, and once the value of x changes theCoroutineScope will be cancelled within it. On the other hand when you only put your if conditional directly inside your Composable, if it is recomposed and
x
evaluates to true then
callLambda()
will be called on every recomposition.
s
Yes, and that’s why this is a very important thing not to get wrong. So I was looking for if there’s some official doc which explains this exactly, I wanted to share it with other people, not so much for myself as I am aware of these issues 😄
c
ahh I see 🙂
I can’t really find an explicit example about it. But the Thininkg in Compose and the Side-effects parts of the Compose tutorial on Developers explains kinda the same
s
Yeah I ended up linking them the side effects page, and this page, and explaining why composables need to be idempotent, and how doing things in composition breaks this