When an initial page is provided to the widget to refresh it, and the second page was the last page loaded beforehand, the second page will not be requested when it should. about infinite_scroll_pagination HOT 14 CLOSED

Hi @hacker1024 .
I'm sorry for the delay. I'm on a trip right now and will be back in 10 days or so.
As soon as I'm back, I'll help you with that.
Thank you!

from infinite_scroll_pagination.

Thanks, I'll test it when I get the next opportunity (hopefully later today).

from infinite_scroll_pagination.

Hey @EdsonBueno , My issue was solved with bugfix/page-request-refactor branch.

from infinite_scroll_pagination.

@awnigharbia and @hacker1024
I finally released this fix on version 2.2.3!
Thank you for your patience.

from infinite_scroll_pagination.

@hacker1024 Try replacing the code inside the if with _pagingController.refresh(). Tell me if it works, please!
If it doesn't work, I'll need a sample project.

from infinite_scroll_pagination.

Unfortunately, I can't use _pagingController.refresh() here because the new request is made by my state management, which calls load() again. As my code duplicates the refresh code without the duplicate request, however, I doubt using it will fix the issue. I'll make a sample project.

from infinite_scroll_pagination.

This issue was too tough to replicate, but I've diagnosed the cause.
It's not about the loading state like I originally thought, but instead about _lastFetchTriggerIndex.

When I refresh my list, I download the first page again manually, and then provide it to the PagingController.
As the widget never requests the first page itself, the status goes straight from completed to ongoing, and this code never runs. _lastFetchTriggerIndex is never reset.

As a result, when the second page was the last page that was loaded before refreshing, it will not be requested again after refreshing.

This only applies to the second page specifically, because if a later page was the last page loaded, the scond page would load before it and overwrite _lastFetchTriggerIndex.

Do you have any ideas of how to fix this?

from infinite_scroll_pagination.

@hacker1024 Can you test it with the code on the bugfix/page-request-trigger-index branch?
If it works I'll release it.

from infinite_scroll_pagination.

Unfortunately, it's causing some problems. I'll debug and get back to you.

from infinite_scroll_pagination.

Okay, here's what's happening now:

1. User opens screen, first page loads.
2. Data is modified on the server.
3. User scrolls down, _pageRequestTriggerIndex is set to the next page's value, the next page tries to load and fails. Error text is given to the paging controller instead.
4. User refreshes the page, which results in the first page being downloaded and provided to the controller.
5. User scrolls down. The newTriggerIndex is the second page's value, which is compared to _pageRequestTriggerIndex - but this has not changed since refreshing, and has remained set to the second page's value. _hasRequestedPageForTriggerIndex remains true, and the second page is not requested when it should be.

from infinite_scroll_pagination.

Hi @hacker1024 . I'm back!
Please, can you test it again with the code on bugfix/page-request-refactor?
I also changed that code from your merged PR. So, it would be great if you could also test this.
Thank you! I'm waiting your feedback.

from infinite_scroll_pagination.

@hacker1024 any news on this?

from infinite_scroll_pagination.

Hi @EdsonBueno, I have a problem when use _pagingController.refresh()
this function should work to clear the data and then reload the data it gets, it's right?.
If so, what happened to my project was not the case, but instead the data increased and did not empty the previous data.

I used this example on my project.

from infinite_scroll_pagination.

@verkit Can you share a toy project reproducing the issue? Since the example doesn't have the same bug, it's probably something on your end.
As this is not related to this issue, please send me via chat.
Thank you so much!

from infinite_scroll_pagination.