I'm trying to have an InputField on the screen, but the input field is just a button that opens up a modal (my designers decision) Any idea why something like this doesn't actually function properly. The onclick is never called and it just leave you to type in the field.

@Composable
fun FakeInputFieldButton(modifier: Modifier, onClick: () -> Unit, valueText: String) {
  val someFunc = {}
  OutlinedTextField("text", {}, modifier.clickable { someFunc() })
}

Probably because the text field consumes those touch events before

clickable

gets a chance to.

I've thought about just drawing myself, but my designer wants the focus color (purple in materials case) to be enabled when the modal is open. And a few other minor things (like error messages), but yes I agree that that's probably easier. Even so, I was curious how a parent clickable doesn't get the click event before the text field.

You could also probably write your own clickable implementation that listens on the initial-pass instead of the main one, but even if that works for this case it doesn't recurse.

Relevant: https://stackoverflow.com/questions/69142209/jetpack-compose-how-to-disable-gesture-detection-on-children

write your own clickable implementation that listens on the initial-pass instead of the main one,

TIL that there are different passes in clickable

I was curious how a parent clickable doesn't get the click event before the text field.

Because if you put a button as a child of a clickable card, it would be weird if you tapped the button and the card is what clicked

Hm. Okay. Actually yeah. Thats a good point that clickables should pick the clickable that you can drill down into the most. In that case then... I should be able to set clickable to null on the TextField, and give the parent a clickable, and I'd be back in business? Already submitted my PR, but I will try this later today. Not the biggest deal if my intended behavior doesn't work. I realize it's kinda hacky, but figured I'd ask to make sure I wasn't missing any magical arg or something (and I got to learn about readOnly arg too.) 😃

it helps to think in terms of additive behavior instead of subtractive, and we've followed this through the compose API surfaces. If you find yourself wanting <some component> but without <x> then the cleaner answer is always going to be to find out how <some component> does everything except X and do that, rather than try to figure out how to stop <some component> from doing <x>