I have a composable that has a lot of parameters, ...

# compose

[youssef hachicha]

I have a composable that has a lot of parameters, for me to improve readability I removed all the parameters added a class for those params and used, CompositionLocalOf.

in the docs its says that
Avoid CompositionLocal for concepts that aren't thought as tree-scoped or sub-hierarchy scoped. A CompositionLocal makes sense when it can be potentially used by any descendant, not by a few of them.

but in my case these params/states are heavily used across almost all of the child composabels.
I was wondering is there any downside for this approach ?

[Stylianos Gakis]

You can create a class but not make it a composition local.
The downsides are exactly what the docs describe. They create implicit dependencies and complicate your code unnecessarily when all you want to do is just pass down one class.

[youssef hachicha]

regarding the class,
when I create a class, in compose I need to have a custom saver for that class and some values of that class could not be converted to primitive values, what is the solution ?

[Stylianos Gakis]

So are you saving this class in a rememberSaveable or something like that to need to persist it with a custom Saver?
How were you doing it before which breaks when turning it into a class?

[youssef hachicha]

so going back at my first question i said that I have a composable function that I am passing a lot of parameters, these params/ state are coming from my viewModel in this case if a configuration change happen my state is safe cause it is in my viewModel
now since I want to make a class in which I group all the states I was passing to my composable
I am gonna have something like this
val customClass = remember(keys){mutableStateOf(CustomClass(...)}
but since the keys I am passing are state coming from my viewModel in case of a configuration change my customClass will persist because the keys I am passing to the remember are state coming from the viewModel.
i guess I am just confused and I don't need a custom saver

[Stylianos Gakis]

The ViewModel will stay alive through the configuration change, so you are not losing the data from there.
• You could just create this class directly in the ViewModel itself
• You could also just do `val yourClass = remember(input1, input2) { Class(input1, input2) }
• Or even just val yourClass = Class(input1, input2)
And in all those scenarios you will not lose the data on config changes.

You also do not need to create this class with mutableState as you are doing there.