Appending an Empty Page when List is Empty, Signals Completion

[behnamsattar]

I am reaching out to report an issue that arises under a specific use case while using the infinite scroll pagination plugin. In our implementation, there's a possibility of encountering empty pages prior to completely loading all items.

When empty pages are appended to a list containing items, the plugin behaves as anticipated. The issue arises, however, when the list is initially empty. In such cases, appending an empty page seems to halt the fetching process for subsequent pages and displays an empty list view.

Upon investigating the source code, I believe this line could be the source of this problem. It appears that appending an empty page to an already empty list changes the itemCount from null to 0, causing _hasItems to return false.

As a temporary solution, I've decided not to utilize the appendPage() method on the controller when both the loaded list and the page I'm appending are empty. Instead, I've modified my implementation to manually fetch the next page without relying on the inherent list logic of the plugin.

[LNA-DEV]

I am also facing the exact same issue. For now I have to try your workaround as well.

[EdsonBueno]

@behnamsattar @LNA-DEV , it doesn't make sense to receive an empty page if there are still items to be downloaded. Think of pagination in a Google scenario: There's no page 2 if page 1 is empty of results. We can't accommodate your situation in this package. I'd solve your problem in your API Data Source layer.

[behnamsattar]

@EdsonBueno Thank you for your prompt response. I understand your point regarding the typical behavior of pagination. In an ideal scenario, having an empty initial page when there are subsequent items is counterintuitive. However, due to limitations and constraints with our backend implementation, there is a possibility for us to encounter this unique situation.

While we recognize that this might not be a common or expected use case for most users of the plugin, the silent malfunction can be quite challenging for those who do encounter it. Addressing this specific edge case in the plugin could provide a more robust user experience for a wider range of implementations.

That said, I completely respect your decision on the matter. If the assumption is that this is an improper use of pagination and isn't aligned with the goals of the plugin, then we will continue to employ our workaround. It's just a suggestion to accommodate situations where the backend doesn't follow typical pagination patterns.

[mateusz-bak]

Spotted the same issue for my implementation. I pull the data from a Public API and filter it locally depending on one parameter. That's why sometimes a page is empty and I want to continue to the next page.

I cannot use filtering as defined in the example _pagingController.refresh(); because when I change my filter parameter while next page is already being downloaded -the API call is not cancelled and will add unfiltered results to my list.

Would be awesome to have a flag like emptyPageAbortsLoading, @behnamsattar please reconsider.

[behnamsattar]

@mateusz-bak I'm not the library's maintainer, and based on their input, I don't think this is being considered. You should be able to get what you need by doing some manual checks on top of what's provided.

[mateusz-bak]

@behnamsattar Thanks, just wanted to add my input here. As a workaround I'm rebuilding the whole list with unique widget key when I change filters so the old API calls are abandoned.