If I add an new slide to the end, then all is fine as the currentSlide remains unchanged, and the user can happily continue to scroll along.
However, when prepending items, as the currentSlide does not adjust, once the slick object has run through reinit, the carousel moves to the item that now has the index to match the previous currentSlide. This can be unexpected behaviour from a user's perspective.
Example: https://jsfiddle.net/niccih/q8x6pw4k/2/
In the above example, a new slide is added, with addBefore 'true', the new slide effectively becomes the currentSlide, so the user now sees 'Slide0' instead of 'Slide1'. Calling 'slickGoTo' does revert the user to the 'correct' slide, but there is that momentary flash of animation which is undesired. I would like to see 'Slide1' remain as the currentSlide, and the prev arrow then become enabled, allowing the user to choose whether to scroll to the left or not.
If the prepend behaviour is by design, in that the currentSlide index remains unchanged, are there any plans to accomodate an argument , to the slickAdd function, that can then adjust the currentSlide value before reinit is called, to ensure the user appears to stay where they are, or is there already a preferred way to achieve the same without the brief movement noticed by calling 'slickGoTo'?
We've run into the same problem and hacked fixed it like this:
In the afterChange handler, add this block before inserting the slide:
element.on('afterChange', function(ev, instance, current) {
// other stuff
if (inserting) {
// a tiny hack makes the earth spin again
// hint: without this, Slick will advance backwards to newly inserted slide.
instance.currentSlide = current + 1;
}
instance.slickAdd(html, current, inserting);
}
We're in production with this right now and haven't had a problem, so I guess I can suggest this fix as a (temporary) solution to your problem.
@teamaton I've been looking for a solution for this issue for way too long. Thanks a lot!
Also, instead of:
current + 1
I had to go with:
current + slickInstance.options.slidesToScroll
as I'm sliding 3 slides at a time.
Thanks again!
@klapec Well, I have to admit that I also spend way too much time on this problem :-D But I'm glad our findings were of any help!
Pozdrawiam ;-)
Most helpful comment
We've run into the same problem and
hackedfixed it like this:In the
afterChangehandler, add this block before inserting the slide:We're in production with this right now and haven't had a problem, so I guess I can suggest this fix as a (temporary) solution to your problem.