adapter.isLoading is not updating

[GrzegorzzBB]

Hello again!

I really appreciate your work. This module is very advanced and satisfies my needs!
I'm working on mobile project (using webviews on mobile devices). Im trying to upgrade ui-scroll 1.3.3 to 1.5.1, but Im still facing some issues. I feed list from remote service, which uses page size and offset as a params. For some reason my list implementation loads only one (first) chunk of data. If user scrolls down nothing happens. He just hit the bottom of the list and it refuses to fetch more items (rows). I put some console.logs on get(), success() and adapter.isLoading.
See the result - interesting part starts from red line to bottom:

• get() method is called for 50 items starting from index 1
• isLoading flag is set to true
• success() is fulfilled with 50 items (starting from index 1)
• get() is called for 50 items starting from index -49 for scrolling up check
• success() is fulfilled with 0 items (starting from index -49)
• isLoading flag is not updated to false state

For version 1.3.3 I got output:

So, its identical except isLoading is set to false after all.

Can you please guide me what should I check/debug to make it work?

Thanks in advance!
Gregory

EDIT:
Project runs on Angular 1.4.9, this might be relevant.

EDIT2:
I put some console.logs at line 885:
console.log('RID', rid);
if (isInvalid(rid)) {
console.log('RID invalid', rid);
return;
}
...and output looks like:

So, it is about invalid RID, but why?

[mfeingold]

Hmm... I certainly do not understand enough of what you are trying to do to give you a solution to your problem, but here are some random thoughts.

First of all even the 'correct sequence' does not strike me as entirely correct. The correct sequence should be start from the start point down and keep requesting more batches until there is enough space or the request comes back with less items than requested. The latter indicates the EOF condition. Then repeat the process from starting point up. In the trace you provided the initial request for 50 items was not followed by another request down even though it returned as many as was requested.

Now the RID stands for revisionID, its purpose is to cancel obsolete chains of requests. You see the initial load or a call to the reload method as well as a number of events (scroll, resize, etc.) initiate a chain of requests to fill out the viewport. The individual requests in the chain are initiated and executed in sequence. Each request in the chain have the same RID. If while the chain is still executed a new event is fired, a new chain with a new RID is initiated. From this moment on the remaining requests in the old chain will be ignored terminating the old chain.

I am still confused as to how come it messes up your use case, but I hope it will help you in troubleshooting. Try to catch why RID was incremented.

Also if you can put together a plunk/jsfiddle with a repro I will try to have a look

[GrzegorzzBB]

@mfeingold Thank you for your response, it is very satisfying answer. What comes to my mind is that I might abuse reload() method... I will check it and I'll let you know.
Thanks!

[dhilt]

@GrzegorzzBB please try ui-scroll v1.5.2, there were some important changes related to your issue!

[wmaca]

I am facing the same problem (and using 1.5.2). The second success callback gets an invalid rid and isLoading never changes back to false. As far as I could understand, visiblity watcher is triggering the second call that invalidates the rid.

[wmaca]

@dhilt After lots of debug, I finally understood where the mistake is. The adapter.get was not correctly implemented. When the total of valid items was bigger than zero, the success callback would be called after fetching my API, an operation that is naturally async. After the fist get call, ui-scroll would try to load the previous pages using fetchPrevious. In this case, as the example stated above, the total of elements that I would pass to success is zero (an empty array, as there are no pages before page number one in my case). As there is no need to reach my API, I would not even bother calling it, calling success right away (not giving a chance to the rest of the ui-scroll code to run). This was enough to get isLoading stuck.

Best, Walter

[GrzegorzzBB]

@waltermacambira It seems to be exactly my case!

I switched to different component, because of requirement change. However, its is really nice to see, that someone successfully debugged and described the case. Thanks!

[dhilt]

@waltermacambira @GrzegorzzBB

I've just prepared demo plunker: https://plnkr.co/edit/yNpY0K?p=info. It has all necessary infrasrtucture: ui-scroll v1.5.2, angular v1.4.9, configurable remote server mock up, even some console logging.

You can play with buffer-size on index.html:28 and with maximum items number on script.js:8. Right now they are set to 51 (buffer-size) and 50 (data-set length) to satisfy fist requirement. I believe this would be enough to emulate your cases. But I was not able to reproduce the issue.

Also I'd like to say, if you look at script.js:101 you will find some code (commented) to prevent API call. This sample is incorrect and must not be used in case of your data-set length more than buffer-size. It's because of offset changing during irregular scrolling. You may see it easily through the console log...

Please fork and update it for I could experience the problem too. Thanks!

[wmaca]

@dhilt like I explanied above, I found the problem and solved it (at least for my case).
When the page requested has zero elements, I call success with an empty array, making adapter isLoading stuck. Using your plunker I could not reproduce it.

[dhilt]

Well... if someone could be able to present a repro of discribed problem (based on https://plnkr.co/edit/yNpY0K?p=info or something else), please fell free to reopen this issue.

[wmaca]

@dhilt the issue is still happening, but really hard to reproduce. I think that it is realated to visibilityWatcher calling adjustBuffer, as my elements are not visible for isElementVisible. Different from the provided plunker, I am using divs that start wihtout any height.

[dhilt]

@waltermacambira
You may describe the sequence of actions (over some real plunker demo) and the probability of the issue happening.. And I will try to reproduce it! Cause you know, no repro, no issue))

[wmaca]

@dhilt what i found debugging:

1. After some scrolling, all fetches are completed and a visilbityWatcher calls adjustBuffer.
2. I start scrolling, it calls enqueueFetch, which returns shouldLoadTop = true, e makes a fetch as pending is empty
3. The adjustBuffer timeout from the visibilityWatcher (step 1) calls enqueueFetch;
4. enqueueFetch sees that is shouldLoadBottom = true, but as there is a pending request, is just enqueues a true
5. The adjustBufferAfterFetch timeout from step 2 runs, notices that there is still a pending request and calls fetch.
6. As buffer.length is not empty and shouldLoadBottom = false, adjustBufferAfterFetch is called
7. From the last buffer change, visibilityWatcher calls adjustBuffer again, cleaning the pending queue.
8. Timeout from adjustBufferAfterFetch from step 6 runs and does nothing as rid is invalid;
9. The timeout from adjustBuffer runs (from step 7), it calls enqueueFetch
10. Enqueue fetch sees it does not have to loadbottom or top, keeping me stuck at isLoading = true.

I am not being able to reproduce it. Actually, I am having a hard time reproducing it at all. I totally understand that we need a repro.

[wmaca]

@dhilt Here is a repro: https://plnkr.co/edit/4QPDISFYGtCuyAQCRmnx?p=preview

To reproduce it, start scrolling really fast (click and drag) up and down, and it will happen.

http://g.recordit.co/zLxGqxJMtc.gif

[wmaca]

Hi @dhilt, did you have a chance to see this? If there is anything else I can do, please, let me know.