No way to limit the data source top?

[SaintFlipper]

I'm using uiScroll to display image thumbnails queried from a back-end service. The images are displayed a float:left DIVs rather than using a table, something like this:

<div ui-scroll-viewport style="height:800px;">
    <div class="imageCell" ui-scroll="item in scrollerDataSource">
        <a class="thumbnail">
            <img alt="IMG" class="thumbImg" overlay-reveal="{{item.summary}}" ng-src="/{{item.imageSquareThumbnailURL}}" ng-click="content.popup(item);"/>
        </a>
    </div>
</div>

I notice that on the first page load the data source get() is called with index=1, 11, 21 as the viewport is filled, and finally with index=-9. A negative index is also specified if the user scrolls down then up again to the top. That's fine in the examples where the item is programatically created and the index is used in the display value, but it has no meaning when querying from a data source with a defined "top", for example here where the "top" is the most recently received image.

In such a case there doesn't seem to be any way to specify that there are no previous items to return. If get() calls success() with an array of items smaller than the requested count then it seems that success() has no way of knowing which items those are. For example if get() is called with index=-5 and count=10 the data source could choose to clip the item array so it only contains the 5 items for index=0..4. However success() doesn't know that those items are for 0..4, and they might as well be for -5...-1 or any other subset.

Currently my data source just ignores any get() request with a negative index and returns an empty set of items. However that results in bizarre behaviour where scrolling down then back up to the top leaves a different item at the top each time.

[mfeingold]

I know this business of negative index makes this math about indexes a bit tricky, especially because of the unpredictability of the scrolling increments generated by the scroll bars.

Ignoring negative indexes is not right. When a bufferSize (default 10) of items is requested let us say starting from index -9, you indeed need to return an empty array (assuming that you want to index your dataset starting with index 1). For starting index -8 the return array should consist of single item # 1 in your dataset. For -7 it should be 2 items # 1 and # 2 and so forth.

It feels somewhat complex, but this is what allows you populate the scroller starting from arbitrary position and then scroll in both directions.

The implementation of this math is actually not that complex. Check for instance this example

[SaintFlipper]

Thanks Michael, that's what I've now implemented, with the service only
returning items which exist within the specified query range. In this case
the 1-based index+count from uiScroll is converted to a 0-based start->end
for passing onto the query service, then the service clips the start index
to 0. Same effect as you suggest though, so a (1-based) index/count of
-8/10 gets converted to (0-based start->end) of -9->1, and the service
returns items 0, 1.

There's a a strange effect when scrolling up though, with the scroller
bouncing requests between alternate high & low ranges. Here's an example -
the blue data source requests are from the initial page load, the green
requests are the result of paging down, then the orange requests are from
paging up again.

data source get : index=1, count=10
data source get : index=11, count=10
data source get : index=21, count=10
data source get : index=-9, count=10
data source get : index=31, count=10
data source get : index=41, count=10
data source get : index=51, count=10
data source get : index=61, count=10
data source get : index=71, count=10
data source get : index=26, count=10
data source get : index=71, count=10
data source get : index=30, count=10
data source get : index=75, count=10
data source get : index=34, count=10
data source get : index=79, count=10
data source get : index=38, count=10
data source get : index=83, count=10

I think it may be the same effect seen in the example:
http://rawgit.com/Hill30/NGScroller/master/src/examples/windowviewportInline.html
where scrolling up results in low numbered items disappearing ever further
off the top of the page.

Is this a known issue, or one to raise?

On 4 July 2015 at 03:04, Michael Feingold notifications@github.com wrote:

I know this business of negative index makes this math about indexes a bit
tricky, especially because of the unpredictability of the scrolling
increments generated by the scroll bars.

Ignoring negative indexes is not right. When a bufferSize (default 10) of
items is requested us say from index -9, you indeed need to return an empty
array (assuming that you want to index your dataset starting with index 1).
For starting index -8 the return array should consist of single item #1
#1 in your dataset. For -7
it should be 2 items #1 #1
and #2 #2 and so forth.

It feels somewhat complex, but this is what allows you populate the
scroller starting from arbitrary position

and the scroll in both directions.

The implementation of this math is actually not that complex. Check for
instance this
http://rawgit.com/Hill30/NGScroller/master/src/examples/positionedList.html
example

—
Reply to this email directly or view it on GitHub
#89 (comment).

[mfeingold]

The colors apparently did not make it to the post. Just out curiosity - are your repeatable items block items, or they are inline? It is a known problem that inline can be somewhat finicky

[SaintFlipper]

It looks like markup is stripped from email replies. Here's the request
list again with comments indicating which requests come from which activity:

// Initial page load
data source get : index=1, count=10
data source get : index=11, count=10
data source get : index=21, count=10
data source get : index=-9, count=10
// Scrolling down
data source get : index=31, count=10
data source get : index=41, count=10
data source get : index=51, count=10
data source get : index=61, count=10
data source get : index=71, count=10
// Scrolling up
data source get : index=26, count=10
data source get : index=71, count=10
data source get : index=30, count=10
data source get : index=75, count=10
data source get : index=34, count=10
data source get : index=79, count=10
...

​My repeatable items are block DIVs:

.imageCell {
float: left;
padding: 4px;
display: block;
width: 204px;
height: 204px;
}
​
I suspect it's the float:left which causes the problem, and maybe that has
the same underlying effect as using an inline element as you mention. If
the float:left style is removed then scrolling up works OK, but of course
that totally changes the display, putting a single item on a line rather
than a grid layout.

Similarly with the windowviewportInline.html example - changing the SPAN
style in that example from display:inline-block to display:block allows
scrolling up to work as expected, but again that changes the layout from a
flow/grid to a single item per line.

Are there any examples of NGScoller with multiple items per row which
scroll as expected? It would be a pity if scrolling was limited to one item
per line, or if the only option was to use tables (which wouldn't
automatically re-layout the items over a browser resize).

Thanks again

On 5 July 2015 at 05:46, Michael Feingold notifications@github.com wrote:

The colors apparently did not make it to the post. Just out curiosity -
are your repeatable items block items, or they are inline? It is a known
problem that inline can be somewhat finicky

—
Reply to this email directly or view it on GitHub
#89 (comment).