Today I noticed the existence of a modifier agains...

# compose

[Marcello Galhardo]

Today I noticed the existence of a modifier against a “default custom Modifier” (see example below). Does anyone know what is the reasoning? And what is the alternative to provide a custom behaviour that can be replaced? That feels like the most intuitive and obvious way of doing it.

For example (that is not a real code as bringIntoView is actually mandatory but you should get the point):

@Composable
private fun MyTextField(
    // other attributes
    modifier: Modifier = Modifier.bringIntoView(), // optional modifier that can be overriden.
) {

And the warning:

Optional Modifier parameter should have a default value of Modifier

[Damian Zawadzki]

I discovered that if you want to have some default behavior in composable that also could be done by modifier you should done it with additional parameter in composable declaration. Take a look on simple composables like Text or Card and see that you have backgroundColor for instance which you could do with modifier but its done with parameter instead. Also we should stick with conventions to have expected behavior on basic stuff like modifier.

[Damian Zawadzki]

Of corse take a look how whole handling of those parameters underneath. I mean stuff like Color.Undefined or contentColor(). You could learn a lot of patterns just looking on open source of those fundamental composables.