kenwheeler / slick

the last carousel you'll ever need
kenwheeler.github.io/slick
MIT License
28.54k stars 5.89k forks source link

Impossible to determine slide direction in `beforeChange` handler with 2 slides #2200

Open leebailey88 opened 8 years ago

leebailey88 commented 8 years ago

short description of the bug / issue, provide more detail below.

The only parameters we get for the beforeChange handler are event, slick, currentSlide, nextSlide. There is no direction parameter. Therefore, going from currentSlide 0 to nextSlide 1 has ambiguous direction that is impossible to determine without knowing more information. Direction can be calculated if there are more than 2 slides because going left nextSlide would be numSlides -1 which can be used as an exception case in calculating direction.

We simply need a direction parameter to be passed to this handler.

leggomuhgreggo commented 8 years ago

@leebailey88 I think you're right. I couldn't figure out a way to detect direction with two slides using the beforeChange event.

It's possible that there's an easier way to do this, but I think either the slideHandler function would need to accept an additional argument soley for direction from the changeSlide function, or there'd need to be a var in the parent scope that stored direction value.

I monkeyed around with it and ended up just modifying the changeSlide method to trigger another custom event.

Assuming there's not an easy way that I'm missing, I support adding direction info to the beforeChange and possibly the afterChange, but it might not we worked in till v2.

qikkeronline commented 8 years ago

I'd like to second this here, definately an issue (ran into it on a few projects)

qikkeronline commented 8 years ago

For anyone who needs this behaviour today:

init slick without arrows

    $(".frontpage-slider").slick({
        arrows: false, // disable built in arrows
    });

then implement your own next and prev buttons in your html and implement the following js

    var direction;

    $(document).on('click', '.slick-next', function(){

        direction = 'right';
        $('.frontpage-slider').slick('slickNext');

    });

    $(document).on('click', '.slick-prev', function(){

        direction = 'left';
        $('.frontpage-slider').slick('slickPrev');

    });

And afterwards you can use the direction variable in your beforeChange event :-)

In my case the animations I trigger on the beforeChange event are turned off on mobile devices; hence the above suffices for me. If you need the animations to work on touch devices you'll need some extra logic.

I still think this would be a great addition to the Slick core; would make an already awesome slider even more awesome 👍

eballeste commented 7 years ago

If you are looking for a way to determine direction and can do it outside of the beforeChange event, you can implement custom div's with slick's prevArrow, nextArrow properties:

$('.slides').slick({
    autoplay: true
    dots: false,
    arrows: true,
    prevArrow: '<div class="slides__nav slides__nav--prev">',
    nextArrow: '<div class="slides__nav slides__nav--next">'
});

Then listen for click events on these custom divs:

$('.slides').on('click', '.slides__nav', function(){
    var direction = 'next';

    if($(this).hasClass('slides__nav--prev'){
        direction = 'prev';
    }

    console.log(direction);
});
notacouch commented 7 years ago

^What about via keyboard?

Slluxx commented 6 years ago

+1 i would like to have a native solution instead of only doing workarounds in a complex project

davevsdave commented 4 years ago

This would be a really useful feature.

eballeste commented 4 years ago

@notacouch didn't think about that, maybe by also listening in on the keypress event and checking if it was the enter key should take care of that. oh, also adding the aria button role to it?

regardless, i've been saying this in every single issue that I get a new notification from, this project is dead. issues should be reaching 1000 issues now and the only recent pull request was a cosmetic update to show more accurate download numbers in npm.