A modern programming language that makes developers happier.

kotlinlang

I am confused about when to call `remember`. Should I wrap `remember` in all object initialization places?

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` .

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:
```@Composable fun a() { println("hi") }```
vs
```@Composable fun a() { 
  SideEffect {
    println("hi")
  }
}```

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. 

<@U0KMMQA20> 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?

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. 