El siguiente código A es del proyecto de muestra oficial.
El Modifier de parámetro se pasa entre las funciones una y otra vez en el Código A.
No entiendo completamente por qué el autor necesita diseñar para pasar el Modifier de parámetro entre las funciones una y otra vez.
Creo que el Código B es simple. ¿Qué beneficios obtendrá el marco de diseño del Código A?
Código A
@AndroidEntryPoint class DetailsActivity : ComponentActivity() { ... DetailsScreen( onErrorLoading = { finish() }, modifier = Modifier .statusBarsPadding() .navigationBarsPadding() ) ... } @Composable fun DetailsScreen( onErrorLoading: () -> Unit, modifier: Modifier = Modifier, viewModel: DetailsViewModel = viewModel() ) { ... DetailsContent(cityDetails.data, modifier.fillMaxSize()) .. } @Composable fun DetailsContent( exploreModel: ExploreModel, modifier: Modifier = Modifier ) { Column(modifier = modifier, verticalArrangement = Arrangement.Center) { ... } }Código B
@AndroidEntryPoint class DetailsActivity : ComponentActivity() { ... DetailsScreen( onErrorLoading = { finish() } ) ... } @Composable fun DetailsScreen( onErrorLoading: () -> Unit, viewModel: DetailsViewModel = viewModel() ) { ... DetailsContent(cityDetails.data) .. } @Composable fun DetailsContent( exploreModel: ExploreModel ) { val modifier = Modifier .statusBarsPadding() .navigationBarsPadding() .fillMaxSize() Column(modifier = modifier, verticalArrangement = Arrangement.Center) { ... } }statusBarsPadding() o navigationBarsPadding() de hecho, cualquier otro modificador debe agregarse en sus funciones relevantes.
En el Código B anterior, digamos que DetailsActivity tiene BottomNavigationBar . Ahora se debe agregar el relleno BottomNavigationBar a DetailsScreen .
No siempre es posible agregar todos los modificadores a DetailsContent (del código anterior) cuando tenemos más funciones componibles o en el futuro, eso se puede cambiar a algún otro.
El mantenimiento será fácil cuando tengamos modificadores en todos los niveles.
Al usar Jetpack Compose, es mejor probar y crear vistas reutilizables y sin estado. Una de las formas de hacer que una vista Composable sea más reutilizable es dándole un parámetro para un Modifier .
Con el Código B , ahora se ha vinculado a cómo se debe mostrar DetailsContent definiendo sus elementos modificadores en la vista más baja de la jerarquía. Esto significa que si hubiera otra vista componible que necesitara usar DetailsContent de una manera diferente, ¡esta otra vista no tendría forma de anular los modificadores dentro de DetailsContent ! (Por ejemplo, ¿qué pasaría si otra vista no necesitara el DetailsContent para fillMaxSixe()? )
Con el Código A , las vistas inferiores en la jerarquía heredan los modificadores de su padre. Esto permite una mayor flexibilidad y reutilización al permitir que los padres decidan cómo mostrar el contenido del componente secundario.
Como se discutió en este codelab de diseños:
La mayoría de los componibles aceptan un parámetro modificador opcional para hacerlos más flexibles, lo que permite que la persona que llama los modifique. Si está creando su propio componible, considere tener un modificador como parámetro, prefiérelo como Modificador (es decir, un modificador vacío que no hace nada) y aplíquelo al componible raíz de su función.
Tengo la costumbre de escribir una función Composable, pasar el parámetro Modifier y hacer referencia a él en la función componible más externa. Así
@Composable fun Simple(modifier: Modifier = Modifier) { Box(modifier){ //... } }Puedes tratar cada componible como una actividad o un fragmento, hazlo a través del Modificador, que puede ser una actividad o un fragmento. ¡Reutilización muy mejorada!