start-index has unexpected behavior when combined with minIndex

[zacronos]

When using start-index to begin loading somewhere in the middle of the data, if datasource.minIndex has already been set programmatically, ui-scroll doesn't properly set viewport.scrollTop(), and so it just keeps prepending data until it gets to BOF.

My workaround for the moment is to use $timeout to delay setting datasource.minIndex -- if it gets set after the first prepend datasource.get, this behavior is avoided.

[dhilt]

Thanks, @zacronos ! This is not a problem of start-index, I suppose, this is a problem of early datasource.minIndex setting. The documentation is unclear: As the scroller receives the items requested by the get method, the value of minimum and maximum values of the item index are placed in the minIndex and maxIndex properties respectively... Values of the properties can be assigned programmatically. But the following conclusion can therefore be drawn indirectly: datasource.minIndex should being set after the first cylce of getting items is done. And this fits the source code. I agree, we should have an ability to set up min/maxIndex before the process run. But currently there is no such a functionality.

Let me see what can be done...

[zacronos]

After some experimenting on my side, I found that I must ensure datasource.minIndex is set after the 2nd call to datasource.get() has completed, i.e. after the cycle that gets items for before start-index. If I even set datasource.minIndex during the 2nd call to datasource.get(), it has the described behavior.

Being allowed to set datasource.minIndex any time (even before the 1st call to datasource.get()) is clearly the most flexible, but it would still be a 95% solution (which would eliminate the need for $timeout) if datasource.minIndex could be set during the 1st call to datasource.get(), and it would be easy to update the documentation to warn users not to set datasource.minIndex before the 1st call to datasource.get() has been initiated.

I took a look at the source code a bit to see if I could put together a PR instead of just an issue, and I'm sure I could eventually, but unfortunately since I don't know the codebase for ui-scroll I couldn't immediately figure out it. If there's anything I can do to help, please let me know.

[dhilt]

@zacronos Thanks and have good luck with codebase research! We have a documented infrastructure for the development: https://github.com/angular-ui/ui-scroll#development. I also will try to find some time from my side for this story and will report if I could bring the goal closer.

[dhilt]

@zacronos I've just drafted a solution, it's in a branch – https://github.com/angular-ui/ui-scroll/commits/min-index – may I ask you to try it in your project? With that code I allowed early min/max indicies setting. Try to set minIndex on your datasource before ui-scroll gets initialized. The processing of early minIndex set should be postponed until first render is done. The main problem was that we have no information on average item height before the first render is done and the branch code fixes that issue.

[zacronos]

I've created a plunker to make it easier to demo the issue and test solutions: https://plnkr.co/edit/EjA47pwEUmnfjj4PriGS As you can see in the code there, I realized I could just set minIndex after calling the success handler, rather than using $timeout.

Notice the variable TEST_MODE; setting it to 0, 1, or 2 will test setting minIndex (and maxIndex) at different points:

• a value of 0 will set the index bounds before ui-scroll gets initialized
• a value of 1 will set the index bounds during the 1st call to datasource.get(), after calling the success handler
• a value of 2 will set the index bounds during the 2nd call to datasource.get(), after calling the success handler

Currently, it is pointing to master, but it is easy to change it to point at the min-index branch instead.

On master: surprisingly, a TEST_MODE of 0 seems to work correctly, leaving item 42 at the top! TEST_MODE of 1 does not (instead finishes with item 0 at the top), but TEST_MODE of 2 works correctly.

On min-index as of right now: a TEST_MODE of 0 or 1 shows the same incorrect behavior as a TEST_MODE of 1 on master, finishing with item 0 at the top. A TEST_MODE of 2 behaves differently, but still not correctly (finishes with item 10 at the top).

[dhilt]

Thanks for demo! TEST_MODE = 0 on 'master' does not take into the account minIndex/maxIndex at all. It's leaving 42, but scrolbar params stay unchanged. That's the branch update. But currently I'm trying it and see that it doesn't work on your demo properly. So I need to investigate it, fix it, maybe write tests, before we can go further.

[dhilt]

@zacronos So I think that I have overcome the issue: https://plnkr.co/edit/5HnDw54gaR0W2yJzYkq9?p=preview – with the latest branch build it looks okey. Correct me if I'm wrong.

[zacronos]

Looks good to me! I fiddled with it a bit, and seems like it's working perfectly. Thanks!

[dhilt]

@zacronos Fine! The fix will be included in a nearest release (1.7.0-rc,3 or 1.7.0). I'll keep the issue open until the new version is released. Thanks for participation!

[dhilt]

Closed due to v1.7.0-rc.3 is released.