Embla-carousel: The Slider is skipping other items

Created on 13 Dec 2019  路  33Comments  路  Source: davidcetinkaya/embla-carousel

Hello, when users swipe hard enough it looks like its skipping other slides, how can we limit it to only one slide per swipe? slidesToScroll: 1 doesn't seem to do anything

const wrap = document.querySelector('.js-home-slider');
  const viewPort = wrap.querySelector('.js-home-slider-viewport');
  const dots = wrap.querySelector('.js-home-slider-dots');
  const homesliderStart = EmblaCarousel(viewPort, {
    loop: true,
    draggable: true,
    dragFree: false,
    speed: 10,
    startIndex: 0,
    slidesToScroll: 1,
  });
feature request resolved

Most helpful comment

@jeiea this feature has just been released with v4.5.0. Thank you for taking time to test this out.

Enjoy,
David

All 33 comments

Hello @leah-cc,
Thank you for your question 馃憤.

The short answer is:

That this is by design and it's intended to work this way.

The long answer is:

That the Embla Carousel animation engine is different from other carousel plugins. It animates by simulating physics and I made this design choice because I wanted a carousel that feels natural to drag and interact with. If I were to limit swipe gestures to progress only one slide, no matter how vigorous the swipe gesture was, that would make the movement arbitrary as opposed to natural, and would go against the very core of how Embla works.

Most available carousel plugins only determine which direction the carousel was dragged and decide whether the carousel should move to the next or the previous slide. If you think about it, this behavior is very unnatural. Because if you were to drag something in real life with a lot of force, it would move further away than if you were to drag it with less force. So Embla not only determines which direction the carousel was dragged, it also measures the drag force. Based on the drag force it will or will not skip slides. It all depends how hard the users drag it.

We have a new browser standard emerging for horizontal (and vertical) scroll areas on websites called CSS scroll snaps, and they also work this way. If you're interested, take a look at this CSS scroll snap example and try dragging it on mobile. I decided to go with the same drag design choice for Embla Carousel. I hope I've managed to explain why I made this choice and that all of this makes sense to you.聽

Kindly,
David

Hi @davidcetinkaya Thank you for the explanation. But Is there a way to adjust the threshold swipe? Because even with very light swipe it sometimes skip items from 1 - 3 or 1 - 5. Many thanks!

Hello @gilbertlucas46,
Thank you very much for your input on this 馃憤.

At the time of writing there's no way to control this externally. If you don't mind, I'd appreciate if you could share a CodeSandbox or a link that demonstrates the issue you're experiencing. Maybe there's something I'm missing here and a demonstration link may help. Because if it's from 1 - 5 it sounds like Embla may be setup in a way it's not intended to be used.

If you're interested, open this CodeSandbox demonstration in a mobile browser. It's a demonstration where you can compare swipe experience between Embla and CSS Scroll Snaps.

Best,
David

Hello, thank you for your reply. If you try to open your. example on mobile. you can actually see what I mean. https://webm.red/view/wrFu.webm

Hi @gilbertlucas46,

Thank you for the screen recording 馃憤.

One thing I noticed: I don't think it's fair to use the dev tools with mouse to simulate touch device swiping, because it鈥檚 not an accurate touch swipe simulation. This is because a mouse on a desktop can swipe with much more force than you could ever reproduce on a real touch device with your thumb. And your users will not use dev tools when swiping. Have you tried this on a real touch device? My recommendation is that you try this on an actual touch device like a mobile or tablet.

What I wanted to convey with the demonstration is that Embla Carousels's drag functionality is designed to work like CSS Scroll Snaps so try swiping in the same manner on the carousel below and they should behave pretty much the same (the carousel below is pure CSS). Both will skip slides if you provide enough drag force.

It wouldn't be natural to not skip slides when decent drag force is applied. That would make the carousel feel stiff, like moving a refrigerator. The movement would be arbitrary just like simple easing as opposed to fluid and natural.
Maybe we should consider exposing an option that makes it possible to configure the friction applied to the carousel, but even then it wouldn't be natural to prevent skipping slides if the user drags the carousel with decent force.

I鈥檓 closing this issue for now. Feel free to reopen it if you want to discuss it further. Thank you!

Hi David,

It's me again! You mention exposing an option to configure the friction of the drag force. Is this something that can be explored?

Thanks,
Sam

Hello again Sam (@akardet),

Thank you for your question. That鈥檚 correct. I mentioned that as a suggestion in this issue but didn鈥檛 get any response from the issue author. So the discussion basically died and the friction option hasn鈥檛 been implemented.

What I had in mind when I mentioned that I could setup a CodeSandbox demonstrating what you want to achieve, was extending Embla with its undocumented method dangerouslyGetEngine(). It has been mentioned in issue #86 in this comment an basically is there for the following purposes:

About the dangerouslyGetEngine(), yes it鈥檚 not documented but it鈥檚 safe to use if you know what you鈥檙e doing 馃檪. The method basically exposes most of the internal Embla Carousel engine, and is intended to aid plugin authors with maximum extensibility. Another purpose is that it enables for extending the carousel with features that either won鈥檛 be added to the core itself, or features that will be released later on.

Are you interested in a solution using this approach?

Kindly,
David

Ahh I see, yeah it would be helpful to see a CodeSandbox example if it's not too much trouble.

Thanks,
Sam

Hello Sam (@akardet),

As you mentioned in our previous conversation you told me that you鈥檙e aware of the design choice with the momentum scrolling. If you still want to use Embla but change that behavior I don鈥檛 mind trying to achieve this and create a CodeSandbox for you, like I suggested here.

I want to mention that I鈥檝e not been able to work on this project for a period now and I鈥檓 hoping to be able to spend some time on it soon. But at the time of writing I don鈥檛 know when that will be possible.

Kindly,
David

For anyone interested, maybe (@leah-cc, @gilbertlucas46, @farshidshahmoradi1996, @akardet), is this close to the desired behavior you would like to see?

https://user-images.githubusercontent.com/11529148/112989433-3614f680-9165-11eb-957e-72721cd287f5.mp4

Kindly,
David

@davidcetinkaya Watching at the clip, I expect threshold for scroll to be decreased. But maybe that will be problem of parameter.
I'll be satisfied with dangerouslyGetEngine() way if you don't want to expose public API for this. Could you provide any hint for this? Currently I stucked at how to get current scroll speed of embla. It seems engine.scrollBody have that, but I can't access to it.

Hi @jeiea,

I expect threshold for scroll to be decreased

I'm not following. How do you mean?

I'll be satisfied with dangerouslyGetEngine() way if you don't want to expose public API for this.

It seems like a lot of people want this so I think I'm going to release this publicly, but I can't give an ETA for it. Recently, I've had a little time to look over some parts of the code that can be simplified so it will be possible to add this feature without adding to the current bundle size.

Best,
David

I think required drag distance to swipe is too long. That maybe due to wide width but it can be shortened. And even if drag distance is short, I will admit it as swipe if speed is fast enough. Because it would be matter of parameter, it's consistent with my expectation overall.

@jeiea, the required drag distance may look like it's long in the video, but it actually isn't. This is because you can't see where I released the pointer in the video.

I expected all swipe cause scroll. But it didn't. What makes difference?

@jeiea I'm just moving the mouse before I actually start dragging (performing a pointerdown and pointerup).

@jeiea The bottom line is, you can鈥檛 see where I release the mouse button after I鈥檝e dragged the carousel on the video, so you can鈥檛 actually tell how far I鈥檝e dragged it. This is because there鈥檚 nothing that visually indicates this. I鈥檓 not using a grab cursor when the mouse button is down for example.

I think required drag distance to swipe is too long

So your assumption about drag distance is probably not accurate in this case.

Ah, I had a illusion that 2, 3, 5th swipes failed to scroll to the next slides. Perhaps reverse elasticity gave me that illusion.

@jeiea ah I see. Your comment makes sense now. Every drag move succeeds in the video. It鈥檚 just that the 1st and the 4th drag is with less force so it doesn鈥檛 bounce back. As you realized, it鈥檚 reversed elasticity 馃憤馃徎.

@jeiea I have a working draft of this feature now. Care to try it out? If yes, please tell me if you prefer a VanillaJs or ReactJs CodeSandbox setup.

Best,
David

I prefer react one.

@jeiea thank you for your swift response. I'll let you know when it's ready.

@jeiea here are the links:

The new option is called skipSnaps. When it's set to false, it will enable the described behavior in this issue. At the time of writing, I'm not sure if this is going to be an option or if it's going to be the default behavior when dragFree: false. You're welcome to share your thoughts about this (and anyone else interested in this of course).

Let me know how it goes.

@davidcetinkaya Sorry for late reply. I showed it to my team, and it seems good.

@jeiea thanks for taking time to test this. I'll release this as soon as I get the chance with v4.5.0. Note that you need to set your options to skipSnaps: false to enable this then.

In the next major version (which will be 5.0.0), this will be the default behavior though.

I just applied it to the real project and found some strange behavior. It seems when loop: true both ends of container are not regarded as snaps. Could you check it?

@jeiea sorry, I forgot to update the CodeSandbox code to the latest. I solved this issue yesterday. Try the CodeSandbox here again and let me know if we're talking about the same issue.

I confirmed that it is the same issue. Thank you.

@jeiea this feature has just been released with v4.5.0. Thank you for taking time to test this out.

Enjoy,
David

It's nitpicking but the read more link in release description linked to localhost.

Thank you @jeiea. That link is important so it's not nitpicking. I've updated the link now 馃憤.

Just added the new option to my app and it's working flawlessly! Thanks for the great work, David 馃槉

Was this page helpful?
0 / 5 - 0 ratings