Slick: Breakpoints do not work properly, again, and still.

[stratboy]

I know you'll do exactly nothing, because it's what you did since the first time you got this kind of request. But I'll write it again, because it's the right thing to do. Tipical use case:

 $(".slider").slick({
    mobileFirst: true,

    responsive: [{
      breakpoint: 830,
      settings: "unslick"
    }]
}

If you start with a small screen, it wil work. As soon as you reach 830 it will unslick. Fine. Than go back to < 830, and you won't have slick back.

So you cannot say your plugin is responsive. It's not. A thing called responsive should behave like a responsive thing. And this is not the case. I think after 2+ years since last time I checked. I come back and guess? Still the same issue.

And by the way: this is not magic, neither.

[eballeste]

listen for the window resize event and reinitialize slick
```
off = windowWidth <= 830;

onResize:
if (windowWidth <= 830 && !off) {
reInitSlick
off = true
} else if (windowWidth > 830) {
off = false
}

[dietantejensen]

reinitializing is the logical thing to do - but I wonder how many people worried and wondered what they did wrong; especially, when the slider works like a charm most of the time.

[eparisio]

it should be implemented
same case here, it should be more clean and fast having an internal method instead of custom external function i think

[stratboy]

@eparisio it has been at least 3 years since my very first request (another thread) about this...

[eballeste]

this repo has not been updated since april. 2018. i think it's time for everybody to move on from slick slider.

[mscoobby]

@stratboy The feature you request is more like "disable" rather than "destroy". And the whole point of destruction is to clean up itself so once destroyed they can't initialised it again. Here a "disable" feature can be implemented but to be honest simple event listener on the resize event does the job perfectly as @eballeste mentioned in his comment.

[stratboy]

@mscoobby I really think that a 'responsive' functionality must be bi-directional.

[mscoobby]

@mscoobby I really think that a 'responsive' functionality must be bi-directional.

@stratboy Yes I agree. They should implement a function to disable it on certain breakpoints, but the destroy function is also useful in some cases.

[mczernow]

When unslick happens, this line is being triggered:
https://github.com/kenwheeler/slick/blob/master/slick/slick.js#L803

because of that resize method won't be triggered anymore, ever. And this is the very method that would trigger evaluating breakpoints. It seems that fixing this won't be that hard, because if we allow to evaluate breakpoints, slick will trigger refresh:
https://github.com/kenwheeler/slick/blob/master/slick/slick.js#L644
if for given breakpoint, the settings property are not unslick.
refresh will then lead to init method, and it's imaginable that we should see the slick to be ready again.

Of course, it may not be that easy. Hard to tell how the system will behave, if we allow it to be active all the time. But it seems to considerably easy to fix it.

[ejazrasool]

@mscoobby I really think that a 'responsive' functionality must be bi-directional.

@stratboy Yes I agree. They should implement a function to disable it on certain breakpoints, but the destroy function is also useful in some cases.

That is true as well, but disable vs. destroy is an implementation detail and the resulting behavior doesn't reflect the literal first two lines of slick website (at the time of writing)

Fully responsive. Scales with its container.
Separate settings per breakpoint

_Separate settings per breakpoint_, nah, in reality one breakpoint (one having settings: "unslick" supersedes all others.

As you said, time to move on.

[eballeste]

move on people! the issues are about to reach 1000 open issues and apparently the only merged pull request was one to get the correct stats on npm downloads. stop beating a dead horse.