IssueTracker

Is this the same issue reported in https://issuetracker.google.com/issues/190788885 which was set as Won't Fix? Because we did follow the recommendation from there to skip the first state, so we will have to revert that code.

Is this the same issue reported in https://issuetracker.google.com/issues/190788885 which was set as Won't Fix? Because we did follow the recommendation from there to skip the first state, so we will have to revert that code.

Yes, part of the intention here is that people will no longer need to add this workaround in their code.

It might be too late for some people, but if people want to know how to tackle this I've played around with it on a pet project ( didn't test this in a prod environment, so a heads up there ):

@Composable
fun <T : Any> LazyPagingItems<T>.refreshLoadState(): State<LoadState> = produceState<LoadState>(
  LoadState.NotLoading(false),
) {
  snapshotFlow { loadState }
    .drop(1)
    .map { it.refresh }
    .collect { value = it }
}

Re comment#10, as explained in comment#2 compose requires an initial state.

Given the most common use case displays paged data right away, defaulting LoadState to Loading means the most common use case will not have to drop first LoadState (versus if it were NotLoading).

I don't get how initial state being anything would affect the use case of displaying paged data right away. Wouldn't the LoadState change before the user has time to notice?

IMHO, initial state being NotLoading would be the sanest choice. In the case of waiting before starting to load data, the correct state would be shown to the user and in the case of loading data right away, it would immediately change to Loading, so the correct state would be shown to the user in this case as well.

Re comment#13, when you call collectAsLazyPagingItems compose launches collection on Pager right away. By the time pager.collectAsLazyPagingItems() returns, data is loading, so initial Loading is the correct state.

Initializing with NotLoading also causes other issues (which is why Paging with Views was also refactored to not initialize with NotLoading):

1. For users who rely on first NotLoading state as indication of refresh complete, they have to manually filter out the first NotLoading
2. If loading animation (i.e. spinners) are based on LoadStates, you could end up seeing a blank screen --> spinner --> data loaded in, and that is not a good user experience.