The following Code A are from the official sample project.
The paramter Modifier is passed among the functions again and again in Code A.
I don't understand fully why the author need to design to pass the paramter Modifier among the functions again and again .
I think Code B is simple. What benefits will the design framework of Code A get ?
Code 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) {
...
}
}
Code 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() or navigationBarsPadding() as a matter of fact any other Modifiers has to added in its relevant functions.
In the above Code B, let's say DetailsActivity has BottomNavigationBar.
Now BottomNavigationBar padding has to be added to DetailsScreen.
It is not always possible to add all the Modifiers to DetailsContent (from the above code) when we have more composable functions or in future, that can be changed to some other.
Maintenance will be easy when we have modifiers at every level.
When using Jetpack Compose, its best to try and create stateless, re-usable views. One of the ways to make a Composable view more re-usable is by giving it a parameter for a Modifier.
With Code B you have now tied yourself in to how DetailsContent should be shown by defining your modifier elements on the lowest view in the hierarchy. This means that if there was another composable view that needed to use DetailsContent in a different way, this other view would have no way of overriding the modifiers within DetailsContent! (For example, what if another view didn't need the DetailsContent to fillMaxSixe()?)
With Code A, the views lower in the hierarch inherit modifiers from their parent. This allows for greater flexibility and re-usability by letting the parent decide how to display the content of the child composable.
As discussed in this layouts codelab:
Most composables accept an optional modifier parameter to make them more flexible, enabling the caller to modify them. If you're creating your own composable, consider having a modifier as a parameter, default it to Modifier (i.e. empty modifier that doesn't do anything) and apply it to the root composable of your function.
I have a habit of writing a Composable function, passing the Modifier parameter and referencing it in the outermost composable function.like this
@Composable
fun Simple(modifier: Modifier = Modifier) {
Box(modifier){
//...
}
}
You can treat each composable as an activity or fragment,make it through the Modifier which can be either an activity or a fragment. Greatly improved reusability!