IssueTracker

We could add an API to make the weighted distance customizable, aosp/3271691 has more info.

I think there are different ways to look at this problem. I'm a bit skeptical about the introduction of a separate composition local for something that can/should be configurable on the visual (overscroll effect) or scrolling (scrollable) side. Esp given that we have the power now to change and rotate thing around.

More importantly, I don't think it is necessarily a setting that is app/theme wide and I can see how it might be desirable to configure such behaviour on list-by-list basis. Given that, composition local seems like not the right tool for the job.

I can see the world where shouldDispatchOverscroll configuration itself would live in the overscroll effect. Granted, it will require the effect to have access to additional info, but I think it might be a sensible change in contract. After all, it might be up to effect to decide when to be shown, and scrollable can just blankly trust the effect to make the right decision.

I can see how it might qualify for an additional parameter in scrollable modifier as well, but I'm not a big fan of this.

I feel like explicit parameter on scrollable makes the most sense - but it's a bit noisy given that we don't expect it to be useful for most platforms. The other big problem is that it doesn't really scale up to every other scrollable component - developers will mostly be using lazy* APIs so we would need to add this parameter to scrollable, verticalScroll, LazyColumn, etc. That's why I was leaning towards a composition local, at least as the mechanism for propagating this - since it's implicit and doesn't require these large cascading changes

The problem I have with a property on the overscroll effect is that it will never be read or used by overscroll effect - from the example in Comment #1 you can see that it is only queried by scrollable, to control scrollable dispatching behavior. Overscroll itself has no opinion / ability to intercept here, it's just scrollable deciding whether to dispatch overscroll based on its own state.

that it is only queried by scrollable

Or, in future, by anchoredDraggable? I think it is ok to have the read to be happening on the caller/consumption side. That being said, scrollable just call overscroll effect and it can rely on this boolean inside it's own logic, which is also ok imo.

The other big problem is that it doesn't really scale up to every other scrollable component

It does scale if we expose OverscrollEffect and allow to configure it in the effect itself?