Shouldn't this be a breaking change? This break th...

# compose

[Tlaster]

Shouldn't this be a breaking change? This break the behavior for drag event handling which we only consume the change if needed before but after beta08 will always consume the change even if we don't need to.

[matvei]

Could you share a use case for which you needed a previous behavior? It is indeed a behaviour breaking change, therefore stated in the release notes.

We carefully considered usecases for this consumption and found that there are little-to-no cases where you would want to decide on yourself when to consume and when to not to consume. Moreover, if we have to ask developers to consume, there's a callback inconsistency, where onDrag is called before onDragStarted for the touch slop, causing the call-sequence contract to break.

The way to fix it and both to simplify the mental model of this usages is to consume always, and allow people to go down the layer and use drag function instead of detectDrag* if they need something a bit more custom.

Does this make sense?

[Tlaster]

The use case for previous behavior is more likely happens when using multiple composable together that handle drag gesture differently, if the child consume all the drag changes, the parent will not work anymore. This happens when I'm using my custom Zoomable with Pager or SwipeToRefreshLayout .

[Tlaster]

And I end up with drag instead of detectDrag* , but it's not that easy to use compare to detectDrag*

[matvei]

It seems like you can benefit from the nested scroll APIs here. Some parents (like swipe to refresh) would like to scroll before the drag happens for example, some after.

In case you want this behaviour to work without nested scroll logic, you can still want to control the consumption flow via PointerEvent.consumed, you can dreate your own detectDragGestures, as it should be ~20 lines of code

[matvei]

but it's not that easy to use compare to detectDrag*

Yeah, I understand the frustration. It's a judgement call, however. It makes other, less advanced usecases way easier and more consistent because the callback order is correct and people don't have to be aware of the consumePositionChange call, similar how they shouldn't care about it in other detect* functions, like detectTapGestures or detectTransformGestures

[Tlaster]

Thanks! that make sense. I just realize that I rarely care about other detect* when I'm using detectDrag* .