Is it possible to determine if a modifier is used ...

# compose

[David Corrado]

Is it possible to determine if a modifier is used such as clickable? Or is it possible to clear the clickable modifier? Or is it possible to ensure a modifier passed as a param is only able to have a subset of modifiers?

[Kirill Grouchnikov]

Doesn't sound like it's feasible to do so. Given an arbitrary (presumably adversarial) modifier, you're asking the compiler or the runtime to detect what exactly it is doing.

[David Corrado]

Yeah I was thinking likely runtime. Basically "Card" has a constructor which takes onClick which I am not sure I fully understand why. It does work around this bug and maybe the reason why is because you can't inspect modifiers
https://issuetracker.google.com/issues/228297205
But basically I want to make it so if someone uses my wrapper of a card and passes a clickable modifier I tell them to not do that.

Are you aware of a feature request for this already? Otherwise ill file it

[Kirill Grouchnikov]

Right but again, how do you expect this to work in practice? How would the part of "I tell them to not do that" work against an adversarial opponent?

[Chris Sinco [G]]

Alternatively you could copy the Card source and fix the modifiers issue, then wrap that instead. Essentially the Card is just a Material opinionated container with shadow

[David Corrado]

@Kirill Grouchnikov it would just be a throw if the clickable was passed. They could remove the throw but hopefully that would get caught in the MR. @Chris Sinco [G] yeah thats fair. That actually is essentially what we have now. We will just keep that then 😃

[Kirill Grouchnikov]

What makes a Modifier to be clickable? Is it a name? Is it some logic inside it? Is it all logic inside it? How does a @Composable function that gets a Modifier determine if what it gets is this vaguely-defined "clickable"?

[David Corrado]

If you add to the modifier clickable then I would imagine we would have some means to detect that. Inspect the variables passed in to the clickable. It's not possible now but that would be my feature request. My rule would be if the clickable modifier is passed at all to throw. Which I am sure would not cover every case but would prevent most user error. I am not saying what the exact implementation would be as I don't understand exactly how modifiers work. Maybe somehow use debugInspectorInfo.name. It just seems like a problem that should be solved that you can not really know about what is going on in the modifier.

[David Corrado]

@Chris Sinco [G] we have an interesting problem with wrapping with a box and I would think the solution would be a little hacky and interested in your thoughts

@Composable
fun AppCard(
    modifier: Modifier = Modifier,
    content: @Composable () -> Unit
) {
    Card {
        Box(modifier = modifier) {
            content.invoke()
        }
    }
}

So in order to wrap and have the clickable be to the box you need to pass the modifier to the box. What is the best practice here as I imagine you would want the modifier to be on the root element? Since we have no means to inspect the modifier we can not just pull out the click and get it to the box but have to put everything in the box

[Kirill Grouchnikov]

There is no means to reliably determine what any given modifier does. It's just a black box that can read from disk or from the internet, or even just flip a coin, and then decide what to do - be it track mouse / touch interaction and be a "clickable", or apply paddings to the inner composables.

[Kirill Grouchnikov]

Essentially, what you are asking for, is a way to "look" at a piece of code and determine what it does at runtime. Which is not decidable.

[dazza5000]

kirill - it depends on how much work you want to do, but you could extend the modifier interface (and only allow the new type to be set on your wrapped class) or wrap clickable and set a property on it and then check the modifier chain

[dazza5000]

you do have a good way of looking at the problem ❤️

[dazza5000]

the maintenance on some of the options would probably be pretty high 🍕

[Kirill Grouchnikov]

There is nothing special in the core Modifier.clickable implementation that makes it a canonical one to handle clicks. If the goal is to prevent the application code to pass any modifier that is tracking mouse and touch interactions and handling them as clicks, then it is simply not doable. If the goal is to prevent the very specific Modifier.clickable one, then maybe indeed to can look at debug info, or unwrap the clickable chain, or do any similar thing that is going to be super brittle in any case.

[dazza5000]

in this instance, we are primarily focused on .clickable