Working with page #/page size vs index/offset

[hornetnz]

I'm wondering if anyone has been able to make this module work using page #/page size API calls? The API i'm plugging into requires these instead of index & offset. Calls when scrolling down are obvious & easy, but because of the way the buffer clears itself, I haven't found a way to make it work when scrolling up. Could the buffer functionality be changed to remove whole chunks instead of half?

[mfeingold]

would you share a repro?

[hornetnz]

I could give you the API source/doc but the specific endpoint that'll utilize endless scroll hasn't been finished yet. I can't share my project due to NDA.

[ribeirobreno]

My take on this was:

• which items are actually being requested?
  • --index; // if using zero based records
  • endItem = index + count;
  • startItem = (index<0?0:index); // if it doesn't have negative items, otherwise just use index
• retrieve pages (often, more than one) based on what index, count and page size i'm working.
  • pageStart = Math.floor(startItem/pageSize)
  • pageEnd = Math.ceil(endItem/pageSize)
  • check if pageEnd >= totalPages, if totalPages is available
• join all the arrays for each page
• slice the resulting array to get the desired range.
  • diff = pageStart * pageSize
  • data.slice(startItem - diff, endItem - diff)

Be aware that ui-scroll's index is one based while the arrays are zero based. In my case it was just the case to decrement the index before anything as my pages are also zero based. #44

[hornetnz]

While I semi-understand what you did, it seems like a lot of fetching and fandangling for something that could be fixed easily with an option in ui-scroll for buffer clip size. Some sort of option that would allow ui-scrolls use of index/offset to keep index a multiple of count so that APIs using page # and page size can use this as well with minimal effort. And similarily, a toggle to not allow negative index would be nice. Flexibility is the key. For now, we've decided to work around this by disabling the removeElement and prepend functions which should work ok considering the relatively small data-size we're working with. We're also considering adding a max scroll down limit at which the user will see a "Load more..." button on the bottom to click to see the next "page". If they're going to load down the DOM, they at least have to work for it this way.