Closed leah-cc closed 3 years ago
Hello @leah-cc, Thank you for your question š.
That this is by design and it's intended to work this way.
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ās 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ām 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ās correct. I mentioned that as a suggestion in this issue but didnāt get any response from the issue author. So the discussion basically died and the friction option hasnāt 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ās not documented but itās safe to use if you know what youāre 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āt 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āre aware of the design choice with the momentum scrolling. If you still want to use Embla but change that behavior I donāt mind trying to achieve this and create a CodeSandbox for you, like I suggested here.
I want to mention that Iāve not been able to work on this project for a period now and Iām hoping to be able to spend some time on it soon. But at the time of writing I donāt 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?
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āt see where I release the mouse button after Iāve dragged the carousel on the video, so you canāt actually tell how far Iāve dragged it. This is because thereās nothing that visually indicates this. Iām 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ās just that the 1st and the 4th drag is with less force so it doesnāt bounce back. As you realized, itās 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 š
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