IssueTracker

Jetpack Compose version: 1.6.0-beta03
Jetpack Compose component used: androidx.compose.material3:material3:1.2.0-beta01
Android Studio Build: N/A
Kotlin version: 1.9.21

I've been testing the new PullToRefresh implementation in M3 and finding a number of issues, both functional and API ergonomics.

1. No exit animation when endRefresh() is called

This one is fairly straightforward and visible in the attached example. I would expect this to animate the progress indicator back to rest.

2. The indicator is always drawn above the content, including on top of other content

This is more serious bug, as it results in what looks like a floating artifact in the UI. The indicator implementation seems to assume that the container is always pushed up against the top of the display, and thus wouldn't worry about drawing the indicator. However, when used in even simple scaffolds with a top app bar of some sort, it will draw the indicator (even when not refreshing) on top of the app bar. This is visible in the attached examples as well.

3. The container intercepts upward scroll events in nested scrolling conditions

This is visible in the attachment as well. In a scaffold with a collapsing/moving top bar, the container will actively intercept upward scroll events in some cases and prevent expansion of the top app bar.

4. The API is awkward and a regression from the M2 implementation

The M2 implementation offered an onRefresh: () -> Unit callback that made using this dead simple. It also better aligned with what this UI ultimately is - a glorified refresh button implemented as a gesture. In the new M3 API, there is no such hook. Instead, one has to directly observe the isRefreshing boolean state. In simple cases (such as the samples) where the UI is directly suspending/blocking on some refresh call to the data layer, this works ok. However, it quickly breaks down when interacting with more real-world cases where a refresh event is signaled to the data layer (such as via LazyPagingItems.refresh()) and awaiting an updated load state.

The result is that the user has to manually implement this synchronization of states. If it's refreshing but the pager load state isn't loading, you now have to independently track if

• You previously kicked off a refresh and now the source is done loading
• The user initiated a refresh and you need to tell the source to kick off a new refresh

I've attached a screenshot example of what this synchronization tedium looks like in practice