Another question (heh): How do I enable/disable a component in compose? Is there some sort of Comp...

# compose

[Kevin Hester]

Another question (heh): How do I enable/disable a component in compose? Is there some sort of Composable I nest it inside or some other concept? (In my case I have a list of bluetooth devices RadioGroupTextItems inside of a RadioGroup. And I want some of those items to be drawn grey/disabled because they are not yet paired with the phone (so I want the user to know they exist, but you can't yet select them)

[Kevin Hester]

oops - never mind. Found it: Emphasis

[Kevin Hester]

hmm - though that just changes appearance, the radio item is still selectable by the user. looking still...

[Leland Richardson [G]]

yeah i’m not sure we have a way to disable input etc for a subhierarchy

[Leland Richardson [G]]

we might though

[Leland Richardson [G]]

cc @Ryan Mentley

[Leland Richardson [G]]

seems semantics related maybe

[Kevin Hester]

ooh yeah - I'd love to use it if you have it. related question if I nest a component inside a ProvideEmphasis do you have anything like emphasisLevel.default? so that I could say something like this:

ProvideEmphasis(emphasis = if(it.isEnabled) EmphasisLevels().default else EmphasisLevels().disabled) {
    RadioGroupTextItem(
        selected = (it.isSelected),
        onSelect = { changeSelection(it.macAddress) },
        text = it.name
    )
}

[Ryan Mentley]

It is only tangentially semantics-related, but I do happen to know the answer...

[Kevin Hester]

currently on emphasis levels I see three choices but nothing that makes me thing "this is the standard default level"

[Kevin Hester]

medium?

[Ryan Mentley]

which would be that you disable components by not providing the onWhatever callback - see, for example, Button, which handles this

[Kevin Hester]

ooh thanks!

[Ryan Mentley]

RadioButton, unfortunately, does not yet, which would be a good feature request

[Ryan Mentley]

or at least a quick skim of the code suggests it doesn't

[Ryan Mentley]

Feel free to file that in the issue tracker with your use-case, we should do that

[Kevin Hester]

ok - will do

[Kevin Hester]

https://issuetracker.google.com/issues/149528535

[Leland Richardson [G]]

by not providing the onWhatever callback - see, for example, Button, which handles this

this is more a component providing a disabled/enabled API which isn’t quite the same as toggling an entire sub-hierarchy

[Leland Richardson [G]]

which it sounds like we don’t have a mechanism for

[Leland Richardson [G]]

i’m not sure it’s an API we want to have, but not quite the same thing

[Adam Powell]

Yeah I don't know that we want to be toggling interactivity and visual state for arbitrary sub-hierarchies like that. Android's drawable states around this sort of thing have always been super weird and people tend to want it to behave in special ways pretty frequently

[Adam Powell]

I'm also not sure about the convention of not providing a callback doubling as disabling an element. It saves a parameter in the function signature but leads to some bizarre code shapes, it's kind of counterintuitive and it might do odd things to some allocation optimization opportunities we might otherwise have

[Ryan Mentley]

Part of me thinks "oh this could be a great use for an Ambient, that way it's only provided to things that opt into caring rather than the current state in View where you can disable a LinearLayout, and what does that even mean?" But then another part of me wonders if that sort of gets back to the same spot where you could disable a subtree that doesn't actually contain anything disableable...

[Ryan Mentley]

Also I share Adam's skepticism about that not-providing-a-callback API - partly for the additional reason that sometimes you want to receive a callback when a disabled item is clicked, so you can tell the user why it's disabled.

[Ryan Mentley]

could always add something like onClickWhileDisabled of course, and maybe that's less surprising...

[Leland Richardson [G]]

I strongly dislike the no-callback-means-disabled convention as well, so i’m glad we all seem to be on the same page…

[Leland Richardson [G]]

IMO there should just be an enabled parameter. this is way cleaner usually than providing an if (disabled) { … } else null as an argument everywhere