Scroller gone wild

[LiamK]

Hi --
I have been using ui-scroll and mostly it is great. However, there are a couple things that need some attention. I'm hoping someone can come up with a fix -- I don't think I'll be able to fix it myself, and that means I'd have to go back to pagination, which I'd really rather not do.

First, if I click on one of my scroll items while the datasource is still scrolling (i.e. it's in the process of requesting data from the API and updating the page) it takes me to a detail page where I can view the item. But, the datasource keeps requesting items from the API. It /never/ stops, even though I'm on another page.
This seems like a bug, although maybe there is something I am doing wrong.

The other thing is that if I have scrolled down, let's say, fifty items and then go to the detail page, when I return to the previous page (the search page) ui-scroll appears to find its way back to where I left off (that's a good thing!) by incrementally scrolling through all fifty items until it gets to the right place -- not so good. That seems really inefficient!

Any help would be very much appreciated!

Thanks,
Liam

[dhilt]

The 1st issue is truly a bug. We have created an issue within our main repo: Hill30/NGScroller#64.
The temporary solution I can suggest is to block UI until the requested data has been loaded and rows have been rendered. This can be done via "is-loading" attribute.

The behaviour that was described in the 2nd issue is surely inefficient, but it is supposed to be that. If your app use cases are so that the scrolling (up + down) events are pretty often then I can recommend you to make a scroller data cache layer to reduce time needed for server responding. Here is the demo of scroller data cache implementation. In current version there is no possibility to reduce time needed for rows rendering.

[mfeingold]

the bug is fixed in see pull request #372

[LiamK]

Thanks! Appreciate it.