suggest] I would like a key-based pagination method.

[crucifyer]

hello. Thanks for making such a nice plugin.

Due to the nature of the infinity scroll, it would be better to make it work in a different way, so I suggest it. Instead of the page number system, it would be better to use 'key(post number) and next (or previous) quantity'. It seems that there is no need to fill in the missing part in the middle. In this way, if you search up to page 2 in the conventional way, write a new article and then search page 3, you can also solve the problem of one article being viewed repeatedly.

_afterKey, _prevKey

_fetchAfter(key?) {
  append - If key is null, _pageSize from the beginning
}
_fetchPrev(key) {
  prepend
}

If you do this, these problems will naturally be solved. https://github.com/EdsonBueno/infinite_scroll_pagination/issues/230 https://github.com/EdsonBueno/infinite_scroll_pagination/issues/231

thank you.

[clragon]

I have thought alot about whether it would be better if the package used Map<KeyType, List<ItemType> in the controller. That is how my controllers originally worked before I switched to this package. The benefit was that you could immediately know what pages have what items and you could replace pages. It also meant you knew what pages were already loaded. Technically you could even skip pages and then load upwards until you reach old pages again (though this would require some extra UI, I guess?). The disadvantage was that replacing items and filtering them was difficult. I have considered implementing my own pagination controller that just does that but its too far from the current interface. The controller could of course still provide a list thats just the flattened items over all pages.

[clragon]

closing this in favour of #56