When I use `Modifier.detectDragGesturesAfterLongPr...

# compose

[Zoltan Demant]

When I use Modifier.detectDragGesturesAfterLongPress and move items in a LazyColumn around, right at the moment where their indexes swap, theres a brief highlight from the Modifier.clickable indication that Id like to get rid off. I think its due to a recomposition happening to reflect the items new placements (which is okay); and that the clickable modifier is triggered first, before leading into the event being a long press. Any ideas on how I can work around it? Code in 🧵

[Zoltan Demant]

Card(
    modifier = Modifier.draggable(),
    onClick = {
        ...
    },
    content = {
        ...
    },
)

Modifier.draggable is basically Modifier.detectDragGesturesAfterLongPress, just involving logic for moving the items around, which I dont think is relevant.

Note: I think I could solve it by manually specifying indication = null in my click handler during drag events. Or it could help to place the draggable modifier last in the chain. I dont know if the latter works, but regardless - Id prefer a better solution since I need the onClick parameter in my card to be used "in the card" for other styling logic, elevation, etc.

[Zoltan Demant]

In onDrag I do change.consume() not sure if theres anything else I can do there to solve this?

[Zoltan Demant]

New week, new possibilities! Anyone know of a fix/workaround for this?

[dorche]

Have you tried the order of modifiers theory already? If you don't use a Card but some simpler composable that lets you specify all the modifiers (and order) manually, does that correctly not show the ripple?
Tbh thinking about this I'm not sure if you'll ever get a clickable and draggable element not show a ripple with the provided modifiers - gut feel is you'll need to do things like you said - no indication or something similar.

i.e. the ripple is shown on "mouseDown", which is too early for the framework to know if this event will be a long press or not

[Zoltan Demant]

I kind of agree, either order of modifiers will work or Ill have to disable the ripple during a drag event. Not sure if disabling it will work fast enough though, since it happens right at the item swap Im assuming its due to a press event happening before the long press to drag is picked back up. Time will tell, Ive just left this alone in case anyone has a simple workaround, otherwise Ill get back to it in a few days and post my findings here!

[Zach Klippenstein (he/him) [MOD]]

File a bug

[Zoltan Demant]

✅ It was actually a bug on my end of things! What basically ended up happening was that items of different sizes were being swapped 2x due to the larger ones overlapping the small ones enough to swap back right after a swap happened already. Of course, nothing visible besides the indication going nuts since the items kept their animated offsets 😅 I even think that Modifier.pointerInput is returning the exact same instance, even after the item has moved - which I did not think was the case before! So the drag event literrary continues, despite the item being moved. Maybe Im wrong, but if thats the case, very cool; Im guessing something similar to moveableContentOf is happening under the hood!

[Zach Klippenstein (he/him) [MOD]]

Oh yea, if your items are keyed then when they’re subcomposed it doesn’t matter what order they’re subcomposed and each individual item should keep its composition and layout state even when they’re reordered. That’s the main reason to use keys with lazy lists

[Zoltan Demant]

Basically my reaction: very nice Makes me appreciate compose even more than I already do! Thanks for the explainer.

[Zach Klippenstein (he/him) [MOD]]

The same is true for anything composed in a loop if you use the key composable btw. Very similar to movable content behavior wise but simpler mechanism under the hood and it’s been around since 1.0

[Zoltan Demant]

Oh sweet. Ive used that in a few places where I needed to have Columns of items inside Cards, inside LazyColumns 😅 Never knew it actually made a difference though!