IssueTracker

Yes, we basically just changed the default behavior for the empty case for now. Please track this bug b/179397301 for the following work in this space.

yes, it is expected as the paging is starting loading asynchronously and there is always at least one frame when there is no items yet

Where can I find the new bug? this issue affect me as well.

In my case .cachedIn(viewModelScope) preserves data from loading again, but scroll position is still resetting to the start every time I navigate to another composable and back. I use LazyColumn with header (item element before items), so that might be the case

Check if you have any other item in the LazyList outside the paged items it will lose position.

If you have any comment it out and see if it still lose position.

I have found a workaround that works for me.

The LazyPagingItems.kt file was copied from the androidx.paging:paging-compose artifact into my project (it doesn't have any other dependencies).

I modified it to add a flag inside the LazyPagingItems class:

    /**
     * The number of items which can be accessed.
     */
    val itemCount: Int get() = itemSnapshotList.size


    // The code below was added:

    /**
     * Added to fix scroll state restoration - wait for this flag to be set to true
     * before setting your [LazyListState] on the [LazyColumn].
     * 
     * @author Baptiste Candellier
     */
    var hasRestoredItems: Boolean = false
        private set

The flag is set inside the updateItemSnapshotList() method

    private fun updateItemSnapshotList() {
        itemSnapshotList = pagingDataDiffer.snapshot()

        // The code below was added:
        hasRestoredItems = true
    }

Then on my composable, I wait for this flag to become true to pass the "real" LazyListState, that comes from a ViewModel.

            LazyColumn(
                // Wait for the items to be restored to set the real list state, so that it isn't reset in the meantime
                state = if (lazyPagingItems.hasRestoredItems) lazyListState else LazyListState()
            ) {
                // ... your items here

There might be edge cases but it works for me, I hope it helps.

rememberLazyListState() is doing pretty much the same internally. Could you please elaborate a bit more on why the build in solution doesn't work for you?

Ouch! I'm new on Compose, so don't know how state, rememberLazyListState() works so i directly pass

fun ProfileTab() LazyVerticalGrid( state = rememberLazyListState(), ) }

and while i switch tab from 1->2 and back from 2-> the state of LazyVerticalGrid regenerated, but i didn't try to save in state on globally and pass in composable.

After i seeing this https://developer.android.com/jetpack/compose/state, i understand state and usage of state, and also found that i make mistake previously comment.

https://issuetracker.google.com/issues/177245496#comment20 its works and thank you for check my request and guiding me.

as a lot of people mentioned, LazyColumn can't restore position correct when Paging has a Header
this is because rememberLazyListState can restore position when there are at least 1 element in the list
but if there is a Header or Footer in LazyColumn, then it will restore in first frame when paging's item count is still 0

so I store listState in ViewModel and restore it when Paging item count > 0

val listState = if (pagingData.itemCount > 0) viewModel.listState else rememberLazyListState()

Try this workaround, you need to check lazyPagingItems before use:

    @Composable
    fun MainFrame(lazyPagingItems: LazyPagingItems<PerformanceEvent.Building>) {
        val refresh = lazyPagingItems.loadState.refresh

        // My temp solution
        if (lazyPagingItems.itemCount == 0 && refresh is LoadState.NotLoading ) return //skip dummy state, waiting next compose

        LazyColumn { ... }
     }

Here is a workaround:

@Composable
fun <T : Any> LazyPagingItems<T>.rememberLazyListState(): LazyListState {
    // After recreation, LazyPagingItems first return 0 items, then the cached items.
    // This behavior/issue is resetting the LazyListState scroll position.
    // Below is a workaround. More info: https://issuetracker.google.com/issues/177245496.
    return when (itemCount) {
        // Return a different LazyListState instance.
        0 -> remember(this) { LazyListState(0, 0) }
        // Return rememberLazyListState (normal case).
        else -> androidx.compose.foundation.lazy.rememberLazyListState()
    }
}

Should we still expect a fix from any Jetpack library ?

If your project does not have a deep dependency on the paging3 library, I recommend implementing a simple paging library yourself to avoid all the weird features of paging3. Paging library needs the coordination of the view layer and the model layer. It doesn't make sense to encapsulate these together.

Here's an example from my project. If you don't need to modify the list, it can be implemented much simpler.

https://gist.github.com/FishHawk/6e4706646401bea20242bdfad5d86a9e

Still not fixed in latest versions, workaround works. Please consider re-opening the issue.

Seconded. Still a problem in 1.3.1

https://issuetracker.google.com/issues/177245496#comment24 works

The default case (all of your items are loaded asynchronously) was fixed in comment#2. For Paging, there is the additional requirement that you must be using cachedIn in your layer above Compose (e.g., your ViewModel layer).

However, the case where you have some items available immediately (like a header and footer) and some items available only asynchronously, is not fixed. This is broken whether you use Paging or not - any data loaded from a Flow would suffer this same problem (as they also would not be available in the first composition).

Creating an generic API for informing the Lazy Layout of when all asynchronously loaded items have finished loading (particularly noting that there can be multiple items blocks loading from multiple asynchronous sources) is not something we can solve in the short or medium term.

That being said, we believe there may be a way to solve this in the specific case of headers+footers and a single call to collectAsLazyPagingItems without having to wait for an overhaul of either the Paging or Lazy layout APIs, so we will be reopening this issue to track that internal investigation.

Sounds like Paging and Component are being developed with a lot of various serious issues that are piling with each version, and the team does not have any intention of fixing them. That's alright, at least now we can finally stop waiting for this to be fixed and instead stop using them entirely. Good luck with this.

Compose requires an initial state for valid first composition.

Paging 3's entire architecture is based around emitting data through a Flow that doesn't emit until collected.

Therefore, significant changes within Paging 3 are required to enable initial states in paging-compose without collection. While these changes are not easily resolvable, we hope to address them in the coming year.

https://issuetracker.google.com/issues/177245496#comment23 - how this condition is going to help if you completely remove the list from composition?

This has been fixed internally and will be available in the next release. The next release version is TBD.

In short, the fix works by making cached data immediately available for presentation after config change / navigation. This prevents the list from having zero items right after config change/ navigation so the scroll state will be preserved without requiring workarounds such as comment#24.

That said, it only works if there is cached data to begin with. This means you need pager.flow.cachedIn(scope). Note that any PagedData mapping/transformations should be applied prior to cachedIn(), such as

val pager = pager.flow.map { pagingData -> 
    pagingData.map {
       // map items
    }
}.cachedIn(scope)

Is it going to fix incorrect loadState (Loading) as well (to avoid displaying incorrect refresh indicator to users)?

val lazyPagingItems = viewModel.pagingDataExample.collectAsLazyPagingItems()
val loadState = lazyPagingItems.loadState.refresh // loadState == Loading initially on config changes/navigation

It should be NotLoading if data is returned from cahce and no request to refresh is triggered

Yes it will start with NotLoading if displaying cachedData.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-common:3.2.0-alpha05

I'll note that while some of the changes from this bug made it into Paging 3.2.0-alpha05, the important ones did not - it'll be in the next release of Paging.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-compose:1.0.0-alpha20

comment#51 are you using cachedIn and paging-common 3.2.0-alpha06?

Re comment#51 - please file a new bug with a sample project that reproduces your issue.

comment#52, comment#53- Sorry, I did a mistake, I used function instead of val in viewmodel. Bug has been fixed now. Tested...

Regarding the workaround from comment#24, if you want firstVisibleItemIndex and firstVisibleItemScrollOffset to continue to remain the same in case other code depends on them, it looks like the workaround should be modified to this?

@Composable
fun <T : Any> LazyPagingItems<T>.rememberLazyGridState(): LazyGridState {
    val state = androidx.compose.foundation.lazy.grid.rememberLazyGridState()

    return when (itemCount) {
        // Return a different LazyListState instance.
        0 -> remember(this) {
            LazyGridState(
                firstVisibleItemIndex = state.firstVisibleItemIndex,
                firstVisibleItemScrollOffset = state.firstVisibleItemScrollOffset
            )
        }
        // Return rememberLazyListState (normal case).
        else -> state
    }
}

If there is a combined flow, cachedIn does not seem to work. Could you please confirm?

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

If you call the pager again with collectAsLazyPagingItems(), LoadState will be called LoadState.Loading rather than LoadState.NotLoading.

Re comment#56 - please file a new bug with a sample project that reproduces your issue

Re comment#58 - there's no difference between navigating a single screen away and navigating multiple screens away - in either case, the ViewModel for your original screen stays in memory the entire time and the composition for the old screen is removed.

Please file a new issue with a sample project that reproduces your issue if you are seeing something different.

im having a similar problem as comment#58 but when navigating to another screen. I update some of the room paging elements in the previous composable with lazy column and when i return scroll state is lost, if i navigate and the return without changing any items from room, state is preserved. The workaround of the mentioned comment is working for me so guess it has to do with the paging behaviour rather than my implementation .... version 3.2.1 too

Re comment#60 can you please file a separate bug with a sample app that reproduces the issue?

Yes they do not want the if and placeholders to be inside the LazyColumn we are supposed to use if outside of the LazyColum.

The workaround is to use a fake lazystate until your data is loaded.

See for example solution https://issuetracker.google.com/issues/177245496#comment62

re comment#62 if you are caching the pager flow with cachedIn(), you shouldn't need a workaround. Can you upload a sample app for me to take a look?

Cachein does not keep the data when the app is killed in the background or viewmodel is unloaded.

That's cute but you might actually want to read the issue.

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

my-version = androidx.paging:paging-compose:3.3.5

When otherFlow updates data, an error occurs: Attempt to collect twice from pageEventFlow, which is an illegal operation. Did you forget to call Flow<PagingData<*>>.cachedIn(coroutineScope)?

comment#69 can you please file a separate bug for your issue?