Limit draggable carousel to decrease/increase only one step

[knalle]

I have a infinite scrolling horizontal carousel/slider. Using Draggable (inertia: true, type:"x"). I like the flicking feature - but can I prevent that a fast flick scrolls through several slides?

[GSAP Helper]

It's pretty tough to troubleshoot without a minimal demo - the issue could be caused by CSS, markup, a third party library, your browser, an external script that's totally unrelated to GSAP, etc. Would you please provide a very simple CodePen or CodeSandbox that demonstrates the issue? 

 

Please don't include your whole project. Just some colored <div> elements and the GSAP code is best (avoid frameworks if possible). See if you can recreate the issue with as few dependancies as possible. If not, incrementally add code bit by bit until it breaks. Usually people solve their own issues during this process! If not, then at least we have a reduced test case which greatly increases your chances of getting a relevant answer.

 

Here's a starter CodePen that loads all the plugins. Just click "fork" at the bottom right and make your minimal demo: 

See the Pen aYYOdN by GreenSock (@GreenSock) on CodePen.

 

If you're using something like React/Next/Nuxt/Gatsby or some other framework, you may find CodeSandbox easier to use. 

 

Once we see an isolated demo, we'll do our best to jump in and help with your GSAP-specific questions. 

[knalle]

I wasn't sure it was need this time

But my request also applies to this one I found on the forum:

See the Pen VwKRpYe by glenn_pot (@glenn_pot) on CodePen.

 

So the swipe and flick is fine, but I would like to limit it to one step. E.g. a fast flick on one 1 would still only get it to 2 (or card 7, is it's the other direction).

[Cassie]

You could put the dragResistance up?

See the Pen wvyRWOg?editors=1010 by GreenSock (@GreenSock) on CodePen.

 

That's nice and simple - other harder option would be to change how you're handling the animation progress in the function updateProgress() function. Maybe clamp the newProgress to avoid overshoots?

https://greensock.com/docs/v3/GSAP/gsap.utils

Good luck! Hope this helps.

[SteveS]

If there were a way to get the most recent snap position in the snap function it would be super simple. Based on the docs it doesn't look like there is a way to do that though.

@Cassie Even in the updateProgress() function I'm not sure how one would be able to get the effect he's looking for without being able to receive the current snap position to calculate and influence the next snap position.

[GreenSock]

First of all, yes, Draggable actually populates the .endX and .endY properties immediately when you let go. We don't actually need that here, but I just wanted to mention it. 

 

You can do everything you need inside the snap function where you can run your custom logic: 

// create a reusable snap function. Feed any value in and it'll return the closest increment of cellWidth...
let widthSnap = gsap.utils.snap(cellWidth);

Draggable.create(..., {
  snap: {
    x: function(endValue) {
      // get the closest one to the CURRENT location (not where it's ending with momentum)
      let current = widthSnap(this.x);
      // now snap to the closest position: the previous one, current one, or next one
      return gsap.utils.snap([current - cellWidth, current, current + cellWidth], endValue);
    }
  },
  ...
});

 

See the Pen WNMLRvr?editors=0010 by GreenSock (@GreenSock) on CodePen.

 

Is that what you're looking for?

[knalle]

Thanks @GreenSock and @Cassie 

 

I can see that it tries to limit the drag, however, in the examples I'm still able to swipe quickly and it scrolls through several slides?

[GreenSock]

17 minutes ago, knalle said:

I can see that it tries to limit the drag, however, in the examples I'm still able to swipe quickly and it scrolls through several slides?

Please define "several slides" - when you release, it finds the closest one at that exact moment (not factoring in any momentum) and then limits things to a maximum of one more beyond that. In all my tests, it worked perfectly. I never got it to go beyond that. Are you saying you did? I wonder if you're just noticing scenarios where the "current" one (on release) looks like the "next" slot (because it's technically closest) and it allows it to go one beyond that. You can obviously adjust that in the snap function if you prefer different logic. For example, you could record the "current" one inside the onPress so that it won't allow it to go beyond one in either direction. I just thought you wanted the logic to be based on the release point, not the press point.

 

For example: 

See the Pen rNJomMO by GreenSock (@GreenSock) on CodePen.

[knalle]

Thanks @GreenSock That was the behavior I was looking for  - in the solution, that is... not talking about you :D ... oh well, you always help, so good behavior form everyone here!