https://kotlinlang.org logo
#compose
Title
# compose
c

Chachako

02/22/2021, 7:39 AM
I am confused about when to call
remember
. Should I wrap
remember
in all object initialization places?
h

Halil Ozercan

02/22/2021, 8:33 AM
Think of
composable
functions as callback parameters that you pass to any other framework or library. You do not exactly have full control over how many times or when they are called. These functions are invoked whenever a related state changes. However,
remember
concept is an escape for you to have a predictable, compose-friendly storage. It literally remembers the result of whatever function is passed to it in subsequent invocations. It also supports invalidators through key parameters. If any key changes,
remember
forgets the previous result and recalculates. I probably botched the explanation but Adam Powell might already have given a good answer in this channel, somewhere. Please don't @ him.
So, you should call
remember
if there is something that needs to be remembered in the following invocations of your composable. Also "remember" that any variable that you use in
remember
is a good candidate to be an invalidator
key
.
c

Chachako

02/22/2021, 10:40 AM
Thank you for your answers. In addition, I still have questions, what is the difference between
SideEffect
and direct call? I found that the following codes will also print when the composable function is recombined:
Copy code
@Composable fun a() { println("hi") }
vs
Copy code
@Composable fun a() { 
  SideEffect {
    println("hi")
  }
}
z

Zach Klippenstein (he/him) [MOD]

02/22/2021, 3:32 PM
Side effects are only executed once the composition has been successfully committed. Composition can fail for a number of reasons, including exceptions being thrown from composable functions. A composition generates a list of changes to apply to the underlying tree the composition is managing, and those changes are all only applied when the composition is successful. That is also when side effects are executed. Composition will probably soon be done in parallel on background threads - since state in compose uses something called “snapshots”, every individual recompose scope can actually be composed concurrently. Side effects, however, are guaranteed to always be executed on the main thread.
🙌 1
s

Shakil Karim

02/22/2021, 4:50 PM
@Zach Klippenstein (he/him) [MOD] Can you please explain more about, "every individual recompose scope can actually be composed concurrently". Do you mean a composable, when it's state changes it recompose on different thread, is the order of state changes will be maintain if each recompose happens on different threads?
z

Zach Klippenstein (he/him) [MOD]

02/22/2021, 5:07 PM
Composition shouldn’t cause state changes directly. Composable functions should be effectively “pure functions” that map state to UI (in this case).
Composition should effectively be a read only operation on the total state of your program. This is for a number of reasons: composition can fail, it can happen in parallel on different threads, and maybe others.
When a composable’s state changes (ie one of the State objects it has read changes), the runtime will schedule it to be recomposed for the next frame.
Note that currently composition is not multithreaded - but Adam recently landed a CL that implements it so it might be available in the next few releases.
But anyway every recompose scope is effectively independent. The compose runtime memoizes the function arguments and so it can reinvoke the function at any time, as often as it wants to, and, theoretically at least, on any thread.
2
4 Views