https://kotlinlang.org
Join Slack
Is there a “tri state switch” composable available? (I think no, but…) What are you using for this? ...
# compose
c
Is there a “tri state switch” composable available? (I think no, but…) What are you using for this? To be clear I mean a Switch for which toggling triggers an action, the result of which determines the switch’s final state.
k
I haven't used it but I saw it a couple days ago
c
Thanks, I’m looking at this now because I was looking at 
TriStateCheckbox
. And, also, it turns out that 
Modifier.toggleable
is just implemented with 
Modifier.triStateToggleable
. I was hoping for some existing UI though
k
Ahh, so specifically a 
Switch
element already backed by it. That I don't know 😔
c
Yes. My plan currently is to hack something together with a 
Switch
and 
CircularProgressIndicator
k
How does a switch look like in the indeterminate / mixed state?
?
c
More or less as I described: like a regular switch with a loading indicator on top. Yeah ideally like that (with some additional spinner / indication for loading)
k
That’s not a tri-state though. That’s “loading” state which is separate from on/off dimension
c
In an ideal scenario, also some API to support state changes like checked -> pending -> checked or unchecked -> pending -> unchecked depending on outcome of the action
k
Pending is usually not part of a tri-state / toggleable componentry language
c
That’s an interesting idea and I’d be happy to learn more. Any recommended reading?
k
Looks like you’re looking for some sort of a generic overlay on top of any given composable that shows that the app is processing the user action
Like the “-” / indeterminate state of a tri-state checkbox is definitely not “pending the app decision over the network on what to display next”
c
That’s true. Although in this case the composable is just a switch, the change is isolated to that toggle (not the rest of the UI)
Yeah. Ok from that perspective yes I agree it’s different
Although I find the TriStateCheckbox use of ToggleableState a bit confusing. There’s nothing “indeterminate” about it
At least in the TriStateCheckbox example, it just looks like “partially checked”, not “indeterminate”
So, with that in mind, I’m planning to build a 
TriStateSwitch
(though I could call it something else) which has a parameter 
state: ToggleableState
k
Tri-state checkbox indeterminate state maps to Aria’s mixed state. So something like this
message has been deleted
Where you have a “mixed” selection state based on the children selected / unselected state
message has been deleted
I can see the parallel to the switch which is also a toggleable component, and which could be swapped into these trees
It’s not clear how you would represent that indeterminate / mixed state in a switch though
And again, that mixed state is different conceptually from your “pending the app state update and in the meanwhile show user that I’m doing something” bit
I would find it confusing as a user - unless you extend the same visual behavior to every single component that causes state updates (checkboxes, radios, dropdowns, etc)
c
That’s interesting feedback. Our design discussions internally have led to the following approximate conclusions: • checkboxes are for e.g. forms for which have an explicit submit or save step • switches take effect immediately
Though admittedly this isn’t based on a wide survey of users. Just based on our collective experience.
k
Switch is just a modern representation of the same exact thing as the checkbox.
I don’t think there’s a particular distinction between immediate vs delayed / explicitly initiated by the user between the two.
c
So, if you have some toggleable boolean state that is backed by a value in a database somewhere, what’s your preferred way to surface the toggle?
k
Switch is a more modern representation, and you see that in macOS, Android and other places. I find the mixed / indeterminate state of checkboxes to be really awkward, as it’s never clear what happens when I click that top-level checkbox. And it’s not clear what is the cycling order between those three states. Having said that again, I don’t see any conceptual differences between two-state checkboxes and switches.
This change in macOS Ventura now uses switches instead of what used to be checkboxes
Like this switch (wallpaper tinting) was a checkbox in Monterey
c
That’s interesting because I would have found the checkboxes more intuitive here. I think. In my mind checkboxes are more like include/exclude state, whereas switches are enabled/disabled state
k
At the most basic, it’s really “on” and “off”, whatever that maps to upwards in your application domain
Which is why the “mixed” state doesn’t make sense to me
c
I agree mixed state is not a motivating example of a real use case
Last week I went to get a flu shot and of course filled out a form where you have to check a bunch of boxes about how you’re feeling and whether you’re allergic to xyz
k
Aria chose to use “mixed” instead of “indeterminate” to, maybe, remove themselves from the loaded meaning of “indeterminate”. It’s not helping really
Also don’t get me started on checked vs selected vs toggled
c
Well, thanks for the discussion Kirill. I didn’t know about the association of “tri-state” with a “mixed” state, so that’s useful. I’ll call my switch something other than `TriStateSwitch`…. not sure what yet
139 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by