I have a composable function that gets 3 State lt T gt param

Question

I have a composable function that gets 3 State lt T gt params Is it better to send State MutableState in params or the value inside them

YASAN · Answer

i thought sending the mutable state is better since it maybe reduces the number amount of recompositions but now my issue is that it looks like I cannot create State lt T gt manually to preview my composable

Dominaezzz · Answer

What does send mean I think a code snippet might be necessary

YASAN · Answer

I meant function parameters

YASAN · Answer

```fun ActiveStationItem stationNullable Station isPlaying Boolean playState Int onTogglePlay gt Unit ``` I have these params

YASAN · Answer

Now I just send the actual Boolen int etc variable

Dominaezzz · Answer

Ah I see The convention is to just pass the values

YASAN · Answer

but I can also send the State

YASAN · Answer

Isnt sending State MutableState make recompositions lighter

Dominaezzz · Answer

Don t worry about that That s the compilers job to worry about If the compose team recommends passing values then they ll know to optimise for that case

YASAN · Answer

Uh okay thinking face

YASAN · Answer

I thought the opposite was recommended

YASAN · Answer

thanks

Dominaezzz · Answer

If you look at the material components you ll see the same pattern of passing in values instead of State It just makes testing easier

Adam Powell · Answer

I keep meaning to add it to the compose API guidelines doc and make sure we get a lint check `State lt T gt ` and `MutableState lt T gt ` generally shouldn t appear in parameter lists If you really find yourself in a place where you need more granular invalidations from performing a snapshot read more locally use a ` gt T` instead

Adam Powell · Answer

Passing ` Mutable State lt T gt ` in parameter lists discourages single source of truth vs the alternatives and breaks usage of the property delegates

YASAN · Answer

Im glad I asked smile I thought the opposite up to now will update my code

mattinger · Answer

I recently made this exact same comment in a code review I have a best practices page setup for us and one of the first things in there after naming conventions is to pass values not State objects to composable functions

Adam Powell · Answer

The longer version of the reason is consider if the caller has a more complex state object that holds the source of truth something like ```class Foo var someValue by mutableStateOf class Bar private val foo Foo val computedValue Int get = foo someValue 2 ```

Adam Powell · Answer

which of these two composables with equal snapshot invalidation characteristics is easier to call with a `bar computedValue` ``` Composable fun BazOne value gt Int Composable fun BazTwo value State lt Int gt ``` With the first it s just `BazOne bar computedValue ` With the second it s ```BazTwo object State lt Int gt override val value Int get = bar computedValue ```

Adam Powell · Answer

generally the only times you should reach for a lambda like this without profiling first though are if you re taking a frequently changing e g animating value into a later post composition phase and you re trying to skip composition entirely when it changes

Adam Powell · Answer

otherwise start with passing the parameter by value

Stylianos Gakis · Answer

gt I keep meaning to add it to the compose API guidelines doc and make sure we get a lint check `State lt T gt ` and `MutableState lt T gt ` generally shouldn t appear in parameter lists If you really find yourself in a place where you need more granular invalidations from performing a snapshot read more locally use a ` gt T` instead Has this ever made it anywhere in the official docs so far