An experiment with concurrency?

It has a number of advantages in standardizing scoping, cancellation and completion "callbacks" for things like input and animation

And makes combining those things much smoother

This combines well with the

withFrameNanos

function as the lowest level suspending animation primitive

And is why the composition scopes for both

rememberCoroutineScope

and

launchInComposition

configure the dispatcher and frame clock to assist in supporting all of this such that you can act on the same frame input arrives before composition occurs in response

Reversing that layering and treating an awaitClick as the primitive gets much more complicated

Likely we will lean toward, if you want a complicated button you will need to build your own out of the constituent parts

with one of those constituent parts being raw (yet likely suspending) gesture detection modifiers

I haven't run or tested this but it shows the idea

(with one quick edit there for a bug; please refresh)

as you can see you don't necessarily need a custom button to suspending-await clicks, you just need this little object to hold the awaiters for you

and that object can also provide the

enabled

parameter to those buttons

(one more update to the gist since I wasn't using the derived enabled state)

anyway you certainly can do this but I suspect it adds more complexity than you need. I enjoy coroutines quite a bit but considering how the rest of compose works via snapshot state updates, unless I was combining things in a very situational way I can't see this being a simpler way to deal with clicks in the general case.

Side feedback: I lookes at the documentation of

Button

in

androidx.compose.material

, and I saw that

enabled

makes the button non clickable… why couple the enabled state to the fact that the code can know a button has been clicked? I mean… I understand that it could be for convenience, but on the other hand, it prevents you to support the following use case aimed at improving UX and user understanding: The user sees a disabled button and would like to know why that option is not available. Because the UX designers are so user-friendly, an informational text is shown when the button is clicked telling why the button is disabled (e.g. the inputted data is not valid, or the device doesn't have required hardware…). Right now, it seems it'd need a wrapping click detector to support that use case, making the code significantly more complex when you wanted to improve the UX a little. Have you though about this in the team, and do you already have an idea of how the API could be designed to support this use case without making the simpler one more complex or more error-prone?

The initial API started with the click handler being nullable. The absence of the onClick parameter determined enabled status.

We didn't like what this does to calling code. It means a lot of this:

Button(
  if (enabled) { { doThing() } } else null
)

I don't even remember if that expression is valid; it forces you into the case of conditional braces conflicting with the inline lambda syntax

The alternative is forward declaring your callbacks as vals and separating them from site of use

So that's kind of gross. Combine that with enabled state having a visual effect and we quickly recommended using a separate enabled Boolean param that defaults to true so that you can treat it separate from the reaction you will perform if the user acts on it.

Dispatching the click when the button is disabled then experiences a related problem: developers have to write

if (enabled)

logic in their handlers. Most will forget and won't expect they have to. Who writes tests to click their disabled buttons and confirm nothing happened?

So yes, in the event that you do want to respond to clicks on disabled buttons, you can conditionally apply a click modifier to the button yourself