Add pseudo-infinite scrolling like IScroll

[Narigo]

I've played a bit with IScroll. They have a really cool feature with infinite elements: It uses a callback with "offset" and "limit" which you register a callback for to lazy load additional elements into the slider.

So I'd like to see a mashup between your "regular" and "infinite carousel" mode baked right into Slick: Replace DOM elements that you don't see now with new / older elements, depending on the direction you scroll. When you're at the end or the beginning, get back into "regular scrolling" mode and stop there.

We did this with Slick already: As soon as you reach slide 4, switch into infinite mode, then stay there until our slide-index counter is below 4 again. This works with the "onAfterChange" callback and changing the infinite option there, but it would be a cool feature to have baked into Slick itself. Thanks!

[Narigo]

Oh and we only made this for the beginning of the slider, even though we have a hard limit of 3000 slides or so. Hopefully it won't be too buggy at the end ;)

[kenwheeler]

So how do you do this? Cache the original elements and tack them on and before using callbacks? How do you handle dot navigation?

[Narigo]

Yes, we cache the elements (more or less like IScroll). We have no dot navigation in our infinite scrolling, but that could be possible with an infiniteLimit option, I guess - as long as you don't have an async action to grab the elements. This would be just a way to save a lot of DOM elements then.

So our current implementation is the following: Start regular scrolling without dots and 5 slides. When onAfterChange with slide 4, set infinite mode, reinit and replace dom elements of slide 1 with the next content after slide 5. As long as in infinite mode, check the direction of the last scroll, and replace the slide on the "other side" with the new / older content. When going back again over slide 4, unset infinite mode again, to have the "no further scrolling" effect on the first slide again.

[kenwheeler]

I really want to do this, but it's the dot navigation/goTo method that throws a wrench in the mix.

Let me look into this. This is likely a full-weekend endeavor, but I really do want to refactor infinite scroll to work better with larger sets.

So if I understand correctly, you are tacking on to the end and resetting right? Not removing the same from the beginning? So you end up with a large list, and on loop, a small list again? Not just a small variable list the entire time?

[Narigo]

Not really. We always have 5 DOM elements and replace their contents.

Quick example for 5 slides when scrolling to the right/next slides:

• From slide 3 to 4, replace dom slide index 1 with contents of "pseudo slide" 6
• 4 to 5, replace 2 with slide content 7
• 5 to 1, replace 3 with content 8
• 1 to 2, replace 4 with 9
• 2 to 3, replace 5 with 10
• 3 to 4, replace 1 with 11 etc. Just needs a counter which slide you really look at.

The other way around would replace the contents of the slides with previous content. So in the same example, going back from 4 to 3 replaces dom index 1 with contents 6.

Hope this is better to understand now.. The really hard part should be the first and last rounds - and we're not really having an algorithm for them yet ourselves ;)

snip sorry for e-mail quoting, replying to GH issues from mobile doesn't work too well, I guess...

[supermoos]

Any progress on making this an official non-hacky way, an example of the implementation for reference could be this: http://cubiq.org/swipeview - There's also an explanation of the concept.