Shubham Singh
11/19/2023, 9:25 AM@Composable
fun MyComposable(
value: T,
onValueChange: (T) -> Unit,
) {
...
}
Or
2. Passing the state variable (MutableStateT):
i.e.
@Composable
fun MyComposable(valueState: MutableState<T>) {
...
}
Also, are there any performance differences between the two approaches (considering some composables can get pretty complex)?Stylianos Gakis
11/19/2023, 9:58 AMMutableState<T>
. Either pass T
or () -> T
if you need to defer the read. There's been many discussions about this here and in #compose, do a search for themShubham Singh
11/19/2023, 9:59 AMChrimaeon
11/19/2023, 10:36 AMShubham Singh
11/19/2023, 10:38 AMChrimaeon
11/19/2023, 10:40 AMShubham Singh
11/19/2023, 10:42 AMStylianos Gakis
11/19/2023, 10:54 AM() -> T
is strictly better than MutableState<T>
, as it allows for the same benefits (deferring reads) while allowing more flexibility, like calling it with a constant value without having to create mutableState first, which is typically useful for previews for example.Shubham Singh
11/19/2023, 11:01 AMChrimaeon
11/19/2023, 11:07 AMShubham Singh
11/19/2023, 11:09 AMPerformance Best Practices
pageascii
11/19/2023, 11:21 AMjava.lang.IllegalStateException
Reading a state that was created after the snapshot was taken or in a snapshot that has not yet been applied
If you need further motivation, ^ this rare crash went away when a a colleague switched to () -> T
& (T) -> Unit
for reads/writes. Our code may have had some other root cause, but that's the thing: using MutableState directly tempts you to use it wherever, however. Bad things usually follow bad practices.
For you, the dev, composable functions do not need to know where the data comes from, so try to be as implementation-agnostic as you can.Shubham Singh
11/19/2023, 11:28 AMStylianos Gakis
11/19/2023, 11:39 AMShubham Singh
11/19/2023, 11:40 AMzsmb
11/19/2023, 3:06 PM