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.

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.

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

Composition shouldn’t cause state changes directly. Composable functions should be effectively “pure functions” that map state to UI (in this case).