slickAdd with addBefore set to true results in the user position not being maintained.

Created on 16 Feb 2017  路  3Comments  路  Source: kenwheeler/slick

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'?

Most helpful comment

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.

All 3 comments

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 ;-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NozX18 picture NozX18  路  3Comments

barzev picture barzev  路  3Comments

k-lusine picture k-lusine  路  3Comments

stephane-r picture stephane-r  路  3Comments

Luneya picture Luneya  路  3Comments