improved handling server side (option "serverWait") about scroller HOT 6 OPEN

Agreed - this isn't ideal at the moment, however it does save the server being hammered with Ajax requests, and I've had other reports that how it is currently implemented is quite desirable. What I would like to do is include a throttle option in Scroller so it would be possible to configure a refresh frequency while scrolling.

from scroller.

Implementing the throttle option, should not refresh if the scroller position is still in the trigger boudaries, because that would break the concept of the boundaries.

Let's say the trigger boundaries are considered. If the refresh frequency will be low, it may then happen user scrolls out of visible data, but Scroller will still wait for next refresh event last one happened long time ago. Increasing frequency will improve this, but still the refresh may be done later then crossing the trigger boudary.

I think better from UX point of view would be to extend my proposal, so that it does not redraw data earlier then predefined time after previous redrawing. IMHO it will provide more fluent loading new data.

from scroller.

Agreed - it is at the cost of hitting the server with more Ajax request. My proposal is that if the throttle is set to 0, then the redraw would be immediate, as per your own solution. Otherwise the redraw would be throttled at the given rate.

from scroller.

I'see, that sounds good.

One more suggestion. My digging into this started by bad experience. I want to have really fluent scrolling user experience. So I tried to lower "serverWait" option. The bad thing that happened, is that during scrolling an ajax request was generated before the previous one finished. When user scrolled quickly it could lead to lot of pending ajax request. So I tried to improve that situation, so that new ajax request is not initiated when another one is still active. That lead me to my proposal. I think when you do the throttling you should think of this too.

from scroller.

Yes - DataTables needs an option to abort a request. Thanks for the suggestion. Not sure when I'll be able to implement it as I'm working on other things just now, but I will try to do so in future.

from scroller.

No problem, I understand.
Thanks for taking time to discuss this.

from scroller.