Does `Checkbox` have `onCheckedChange: (Boolean) -> Unit` instead of `onClick: () -> Unit` onl...

# compose

[Rick Regan]

Does Checkbox have onCheckedChange: (Boolean) -> Unit instead of onClick: () -> Unit only to support TriStateCheckbox? I can see why it's there for that but if you are not using TriStateCheckbox (the normal usage case?) it seems strange that it's just not onClick (like Button, RadioButton, TextButton, and even TriStateCheckbox itself). Why not have a second signature for CheckBox with onClick instead of onCheckedChange?

[jim]

Passing in the "suggested state" (when one exists) is the standard we are trying to encourage for all widgets. This is not so important with such a trivial widget, but gets much more important when widgets have any degree of complexity (eg. TextField).

The only reason we don't pass in a state for TriStateCheckbox is that the intended "next state" is ambiguous and needs to be decided by the app developer.

[Rick Regan]

OK I think I see the difference now with buttons since there is no suggested state for them, even though as I am using them now I think of them as Boolean ("toggleable"). Thanks.

[Rick Regan]

But wouldn't RadioButton have a suggested state of "selected" then? Or is it intentional to omit it to cover groups of radio buttons, where you'd want to deselect the other ones at a higher level?

[jim]

Yeah, for RadioButton (which is almost always used in a group and usually you can't deselect all items within the group), the suggested state would always be true, which isn't that meaningful.