What's the reason behind moving towards Modifiers instead of having composables like Clickable and Toggleable? I find it weird having to declare the modifier param everywhere. Is it just because of nesting?

I felt the same at the beginning, but now I just get used 😄

One of the best explanations I saw, or inferred, is a preference that composable functions correspond to widgets / nouns. PRs I've looked at that switch from composable wrappers to modifiers were a lot more readable afterward.

So it's only about readability? Not letting things that don't impact that much steal so many screen space? I feel that this modifier syntax is closer to xml definitions. And it's definitely composable. But it feels off.

Padding(8.dp) {

Text("Hello")

}

is obvious but what about

Padding(8.dp) {

Text("Hello")

Text("Bye")

}

With assumption that they will be position next to each other, in this situation it's not obvious that padding is around all of it or around each one. with modifiers

Row(Modifier.padding(8.dp)) {

Text("hello")

Text("World")

}

the meaning of the applied padding is obvious.

Yea, the compose devs have often referred to confusion about stuff that needs to only take one child since it isn't a layout. There's no way to enforce that if it's a composable function.

Okay that's a good point. But the problem still lies there though. It's because you can't enforce single child that you go this way. Some dev can still define some primitive that will have unclear behavior with two or more children. It's assuming that we use the given primitives because who wrote them already thought about this.

Sure, someone can always write bad code, you can’t really prevent that entirely. The modifier pattern eliminates some ambiguity for the pre-built modifiers at least.

I think it's also a lot nicer to chain Modifiers with extra dots than to have very deeply nested composables. If they are split out across functions, the purpose of those functions becomes unclear and it separates the meaningful code bits apart