IssueTracker

Ideally we would not pass any initial state because it will always have some case where it is wrong - we should ideally wait for a real event from Paging before sending it downstream to user.

For example the initial state:

CombinedLoadStates(
            refresh = InitialLoadStates.refresh,
            prepend = InitialLoadStates.prepend,
            append = InitialLoadStates.append,
            source = InitialLoadStates
        )

...will always have null mediator states, even if they are using RemoteMediator. This can mess up loadstate logic that is waiting for some combination of source + mediator loads to happen. It's easy to filter the initial case, but it gets complicated if they want to switchMap between multiple streams and they all start with this initial state. Or also consider the case when coming from cached state and needing to filter this out... it's bad developer UX.

So we could either set this to nullable to denote "no state" or we could have some constant we use that can be easily filtered out like "BogusLoadState" and then people can do .filter { it !== BogusLoadState }

Alternatively, if we can read whether we have RemoteMediator or not, we could try this for initial state which would be a lot more accurate:

private val InitialLoadStates = LoadStates(
    LoadState.Loading,
    IncompleteLoadState,
    IncompleteLoadState
)

CombinedLoadStates(
  refresh = InitialLoadStates.refresh,
  prepend = InitialLoadStates.prepend,
  append = InitialLoadStates.append,
  source = InitialLoadStates,
  mediatr = ??
)

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.

Fixed and available in paging 3.3.0-alpha03