En Jetpack Compose vemos que todos los componentes integrados tienen entradas aplanadas, ¿es intencionado? ¿O envolver demasiadas entradas con la clase de datos (que es una práctica buena y limpia) tiene el mismo rendimiento?
Considere esta muestra
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 ) { ... }¿Sería mejor enviar entradas como clase de datos o entradas planas en rendimiento (recomposición)? O tiene el mismo resultado?
De otra manera, cuando enviamos una clase de datos a la función componible, y solo cambiamos un miembro de ella, ¿provoca que toda la función se recomponga? O en cuanto a la recomposición, ¿tiene el mismo rendimiento que cuando se usan entradas planas?
Gracias de antemano por su ayuda.
Creo que el impacto en el rendimiento es mínimo al elegir uno u otro. Creo que los desarrolladores de Compose simplemente no pensaron que las clases de datos eran la mejor ruta como parámetro, y estoy de acuerdo.
No veo cómo esto:
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 ) { ... }es mejor que esto:
@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 ) { ... }Tener una clase de datos involucrada en cada interacción con una función de composición con una gran cantidad de argumentos solo agrega una complejidad innecesaria a su código. Agrega más obstáculos para leer la documentación, llamar a la función y comprender en general el código base, por el único beneficio de tener menos código dentro del paréntesis de la declaración de la función (pero más código en el resto).