Only enable wrapAround when slides fill carousel

[desandro]

Test case: https://codepen.io/desandro/pen/xJQwyV

Addressing #95. If you enable wrapAround, but the slides do not fill the carousel, you'll see a bug where the slides will jump around trying to fill the container. One solution is only enable wrapAround if there's enough content to fill the carousel, so this bug does not occur. This feature could be built into Flickity itself, with something like wrapAround: 'fill'.

Add a 👍 reaction to this issue if you would like to see this feature added. Do not add +1 comments — They will be deleted.

Ran into this yesterday - client definitely thought it was a bug - content exactly filled the width of the slider (4 slides at 25% width). These slides are generated dynamically so sometimes there is less content, more content or the same content as the container size. This should be handled correctly (no arrows or slide). And I'm not sure that disabling wraparound would do it for us because at other breakpoints, the slider is fine (e.g. at mobile, there is only room for one slide & 4 can slide without issue). Can you turn off slider functionality at breakpoints where the slider content is too small?

[lxbdr]

I just built this workaround that conditionally enables wrapAround if the cells fill the container
works without modifying flickity (for those who can't wait) - suggestions for improvements very appreciated

https://codepen.io/anon/pen/OaYVZr
(resize the window, notice the cells min-width)

[jamesstcrice]

Same issue as @ikemarrus - was brought to my attention by client. Even just centering the items and not wrapping around would be better than what is happening... which is some unpredictable jumping around depending on the size of the browser. Passed a certain width is just goes wonky.

[the-hotmann]

I just built this workaround that conditionally enables wrapAround if the cells fill the container
works without modifying flickity (for those who can't wait) - suggestions for improvements very appreciated

https://codepen.io/anon/pen/OaYVZr
(resize the window, notice the cells min-width)

I like this feature!!
But you made a "mistake"
at a specific width (when all cells exactly fill the width) you cann see them switching.
This is because you activate this function when all of them are >= width

When you should do:
all cells -1 >= width

Because you one cell still have to have enough space to switch without beeing seen.

[weotch]

FWIW, I do like that Flickity doesn't create new cells with its implementation of wrapAround (unlike Owl's loop, for instance). It makes it easier to integrate with component frameworks (Vue, React, etc). I agree with the proposed suggestion to conditionally enable wrapAround, rather than create duplicate cell instances to fill the empty space.

[OktarinTentakel]

I agree that not having cloned elements in the track is a definite pro when dealing with dynamically initialized slides, but the current wrapAround implementation does not even work with elements filling the viewport horizontally without visual artifacts.

Let's say I define some slides with varying width and put the slider in center mode: now the offset happening in the middle defines when an element on the edge is removed and put on the other side, put that element does not have the same width and therefore due to a small offset in the middle a big element at the edge might be removed and put on the other side.

You cannot even calculate this easily and worse: disabling the slider does not help either since the content well overflows the viewport and we would have unreachable content doing this.

Dynamically disabling wrapAround is no option at all, since it defeats all design purpose behind using wrapAround in the first place.

It all comes down to this: we do (optionally) need a mode with cloned elements or center + wrapAround is not usable.