How do you guys handle complex composables with many parameters? I can combine the value parameters ...

# compose

[jannis]

How do you guys handle complex composables with many parameters? I can combine the value parameters to a state object (which generates more boilerplate code), but I'm unsure what to do if the user can do a lot of stuff. E.g. I have tons of callback methods to pass events to my ViewModel. Also define an Interface with all the possible methods?

[jim]

Great question. Yes, you can bundle the callbacks into a state object. If you go with that approach, I'd strongly recommend taking in an interface rather than a concrete class/implementation.

[Filip Wiesner]

There is a segment in "Thinking in Compose" video from @Leland Richardson [G] where he specifically talks about this issue.

[BenjO]

will the compiler be able to detect fined grained changes using only one big state object ? for now I kept using multiple parameters to be sure recomposition only happens where it needs to be

[BenjO]

I had such issue few months ago on a dashboard screen displaying lot of real time data (multiple bike sensors emitting every 500ms).
I was using only of state object so that my composable use only one parameter. Each time one of the value changed, a new state was emitted, the whole screen was recomposed.

this is mentionned here : https://developer.android.com/jetpack/compose/architecture#composable-parameters

[curioustechizen]

If one value changes the whole screen should not get recomposed if I understand Compose correctly. Only the part of of the screen that uses the property that changed should recompose.

As one of the engineers on the Compose (I think it was Chuck) put it, Compose does work proportional to the size of the change, not the size of the data.

[jim]

Eeh, yeah, I mean, it depends on how you model your data. It is important to keep the references the same or else Compose will see the new reference and be forced to assume everything below that reference has also changed.

@BenjO Was your data object one giant immutable object? Or did you break it up so you have a class with multiple fields and each field is backed by a mutableStateOf? The later allows for more granular updates.

[BenjO]

My first implementation used one giant immutable object. Its properties were primitive values (int, long) and I was hoping that the compiler could only recompose properties that changed. I ended up passing multiple parameters. I did not test your "intermediate" approach with one object/reference backed by multiple mutable states.

[curioustechizen]

@jim could you explain what you mean by "keep references the same"?

[jim]

I mean: Is the object passed into any given composable triple-equals-equal to the object that was passed in during the previous composition.

[eygraber]

@jim my approach has been to collect all the state into an @Immutable data class using a Flow and collectAsState at the root of the composable.

Then I pass the specific (@Immutable / primitive) properties from the data class to each relevant composable.

It seems to be working ok in regards to recomposition, but might there be something I'm missing that can bite me later?

[eygraber]

I think I got my answer serendipitously from https://kotlinlang.slack.com/archives/CJLTWPH7S/p1615691220166000 😄