IssueTracker

Thanks fir this feature request.

Tricky request you have here as it involved more than one request to solve this properly :)

Partially this will be possible, but via slightly different API. I need to see for sure, but ScrollableColumn and friends will consume InteractionState that have Interaction.Drag inside when user is dragging, and, probably, settling (names TBD) when it's flinging. This way, you will be able to react and do smth on the interaction that are happening inside the scroll.

By do smth I mean smth that doesn't affect overall scrolling, but it seems like you want to have exactly this (snapping behaviour). This is somewhat tricky to do right, as snapping after the fling has ended will result with the bad user experience as you want to start snapping way before the fling has ended. So, there should be a proper way to make such UI

Several alternatives here (both from our side and your side):

1. Wait until we expose InteractionState and listen to it + scrollState.value to trigger animations. Tricky and fragile as you will have two sources of truth.
2. Make your own component that does that behaviour using current version of nested scrolling. You can make your own component that uses Modifier.scrollable that wraps ScrollableColumn. When ScrollableColumn hits the bound, dragging deltas will flow to the parent above (not fling though), so you can detect it and trigger anything you like.
3. Wait until we provide proper nested scrolling support and do 2 properly to support this.

I will leave this open until we have InteractionState supported, let me know if you have any questions

Thanks for your response

Indeed waiting for the fling to end is bad for user experience.

1. Would this also expose the velocity? I feel like this solution would basically be the same thing than using rawDragGestureFilter with a less-weird api (except the gesture filter is not getting the velocity). If I'm wrong about it being the same kind of solution with a different API please correct me.

The issue with not having the velocity propagated is that the implementation is not great, since we don't know in which direction the scroll was occurring. So we can only snap depending on scrollState.value. This could be solved by saving the initial position when the drag starts and compare with the value when stopping, but it feels really hacky. So having this kind of information in the state (velocity, and thus direction by its sign, and also the initial value from drag started).

2. It does feel like the current implementation of the CollapsingToolbar view implementation. But I'm not sure I understood it completely

When ScrollableColumn hits the bound, dragging deltas will flow to the parent above What do you mean by "hits the bounds"?

Wouldn't the parent wrapping the ScrollableColumn always intercept the scroll events since higher in the hierarchy? I'm not sure how this would work, since it's not a huge priority, I don't mind waiting proper nested scrolling support. Though I'm not sure how this would solve the issue here, so would appreciate more details if you have time to spare :)

I do feel like snapping is a bit tricky to implement, maybe I should've opened a different feature request for this :)

Again thanks for the details

As I mentioned above, I exposed InteractionState on the scrollable containers (and their states), so you are now able to understand whether fling or drag is happening and distinguish between them. This thought doesn't solve your issue, as you need to wait for a proper nested scrolling support, unfortunately.

Closing this as the main feature request of exposing ongoing scroll/fling is completed, please, follow the rest of the work here: b/162408885