https://kotlinlang.org logo
#compose
Title
# compose
k

Kevin Hester

02/14/2020, 2:11 AM
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)
oops - never mind. Found it: Emphasis
hmm - though that just changes appearance, the radio item is still selectable by the user. looking still...
l

Leland Richardson [G]

02/14/2020, 2:19 AM
yeah i’m not sure we have a way to disable input etc for a subhierarchy
we might though
cc @Ryan Mentley
seems semantics related maybe
k

Kevin Hester

02/14/2020, 2:23 AM
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:
Copy code
ProvideEmphasis(emphasis = if(it.isEnabled) EmphasisLevels().default else EmphasisLevels().disabled) {
    RadioGroupTextItem(
        selected = (it.isSelected),
        onSelect = { changeSelection(it.macAddress) },
        text = it.name
    )
}
r

Ryan Mentley

02/14/2020, 2:23 AM
It is only tangentially semantics-related, but I do happen to know the answer...
❤️ 1
k

Kevin Hester

02/14/2020, 2:24 AM
currently on emphasis levels I see three choices but nothing that makes me thing "this is the standard default level"
medium?
r

Ryan Mentley

02/14/2020, 2:24 AM
which would be that you disable components by not providing the
onWhatever
callback - see, for example, Button, which handles this
👍 1
k

Kevin Hester

02/14/2020, 2:25 AM
ooh thanks!
r

Ryan Mentley

02/14/2020, 2:25 AM
RadioButton, unfortunately, does not yet, which would be a good feature request
or at least a quick skim of the code suggests it doesn't
Feel free to file that in the issue tracker with your use-case, we should do that
k

Kevin Hester

02/14/2020, 2:26 AM
ok - will do
l

Leland Richardson [G]

02/14/2020, 3:08 AM
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
which it sounds like we don’t have a mechanism for
☝️ 1
👍 1
i’m not sure it’s an API we want to have, but not quite the same thing
1
a

Adam Powell

02/14/2020, 2:05 PM
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
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
3
r

Ryan Mentley

02/14/2020, 11:32 PM
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...
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.
could always add something like onClickWhileDisabled of course, and maybe that's less surprising...
l

Leland Richardson [G]

02/14/2020, 11:38 PM
I strongly dislike the no-callback-means-disabled convention as well, so i’m glad we all seem to be on the same page…
IMO there should just be an enabled parameter. this is way cleaner usually than providing an
if (disabled) { … } else null
as an argument everywhere
2
2 Views