In Jetpack Compose we see all built in composable have flattened inputs, is it intended? Or wrapping too many inputs with data class (which is good and clean practice) has the same performance?
Consider this sample
data class SettingsItemEntity(
val title: String,
val description: String? = null,
@DrawableRes val imageResId: Int? = null,
val isChecked: Boolean? = null,
val showDivider: Boolean = true,
val onItemClicked: () -> Unit = {},
val onCheckedChange: (isChecked: Boolean) -> Unit = {},
val buttonLabel: String? = null,
val onButtonClicked: () -> Unit = {},
)
@Composable
fun SettingsItem(
entity: SettingsItemEntity,
modifier: Modifier = Modifier
) {
...
}
Would be better to send inputs as data class or flattened inputs in performance(recomposition)? Or has the equal result?
In other way, when we send a data class to composable function, and we just change one member of it, does it cause that the whole function recomposed? Or recomposition wise, it has same performance as when using flattened inputs?
Thank you in advance for your help.
I think the performance impact is minimal from choosing one or another. I think that the Compose developers just didn't think data classes as parameter where the best route, and I agree.
I don't see how this:
data class SettingsItemEntity(
val title: String,
val description: String? = null,
@DrawableRes val imageResId: Int? = null,
val isChecked: Boolean? = null,
val showDivider: Boolean = true,
val onItemClicked: () -> Unit = {},
val onCheckedChange: (isChecked: Boolean) -> Unit = {},
val buttonLabel: String? = null,
val onButtonClicked: () -> Unit = {},
)
@Composable
fun SettingsItem(
entity: SettingsItemEntity,
modifier: Modifier = Modifier
) {
...
}
Is better than this:
@Composable
fun SettingsItem(
title: String,
description: String? = null,
@DrawableRes imageResId: Int? = null,
isChecked: Boolean? = null,
showDivider: Boolean = true,
onItemClicked: () -> Unit = {},
onCheckedChange: (isChecked: Boolean) -> Unit = {},
buttonLabel: String? = null,
onButtonClicked: () -> Unit = {},
modifier: Modifier = Modifier
) {
...
}
Having a data class involved in every interaction with a compose function with a lengthy number of arguments just adds unnecessary complexity to your code. It adds more obstacles to reading documentation, calling the function, and overall understanding of the codebase, for the single benefit of having less code inside the parenthesis of the function declaration (but more code everywhere else).