Jump to content
GreenSock

leeto

Draggable – "left" resetting to 0px on drag start

Go to solution Solved by GreenSock,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi All!

 

I am in the process of building a simple slider with the GSAP's Draggable inside a responsive(ish) site — only one breakpoint. Basically what the slider does is — as it is being dragged  it updates its' position to the span above. Essentially letting the user know how much percentage they are on the bar.

 

Note:

The draggable's initial starting position is provided by an outside AngularJS service, but in the CodePen test is set to fixed 50%. 

  1. After initializing Draggable(s), we convert that % value into pixel values, and use TweenMax.set() to set the new value.
    • This was done, because because for some reason the Draggable initializes back to left: 0px  and drags form there if the % value is left. Kind of jarring.
  2. When the user stops dragging, then the value is calculated back to the % value, so that when the site is resized then I can keep the draggable relative to it's parent bounds.
  3. Before the drag is started again...
    • onPress: I reconvert the percentage value back to pixel, and then we can start the drag...

Issue (#4):

Number 4 in the list above is where I currently have an issue. The draggable is restarting its' drag position from 0px again even though the left value has already been recalculated back to pixel based value...I basically have to "click" the draggable with full release THEN I can drag without it restarting from left: 0px, and if I just press and then drag it starts from 0px...

 

Any ideas as to what is causing this issue? Or maybe I'm missing something. I've thrown an almost exact copy of my code inside the CodePen below. 

See the Pen znlpu by toulee (@toulee) on CodePen

Link to comment
Share on other sites

  • Solution

Since you're forcing the "left" value to something different inside the onPress, you need to tell the Draggable to update() which essentially re-analyzes that property internally and calibrates itself. Here's the updated codepen: 

http://codepen.io/GreenSock/pen/edf06dac91799e27a975e7de8f8bb0a6/

 

I also noticed some inaccuracies with the way the percentage was being reported (I think that's why you were adding the "limit" thing in there), so I fixed that as well, and avoided the jumpiness that was caused by your Math.floor() of the percentage. It seems to be working smoothly now. 

 

Enjoy!

  • Like 4
Link to comment
Share on other sites

Jack, 

 

Thanks for checking out my issue. Much appreciated! 

 

Thanks for pointing out that update() function. I had thought about using that function of Draggable, but was a hesitant or unsure. Reading through the documentation, I wasn't sure if that was appropriate for this set up considering that I had set the Draggable to type: "left", and the docs specifying that the the Draggable.update() would only update  the "x" and "y" properties (type: y?, type: x?).

 

 

I probably was just reading it wrong.  :oops:

 

 

 

 

Updates the Draggable's x and y properties so that they reflect the target element's current position. This can be useful if, for example, you manually change or tween the element's position, but then you want to make sure the Draggable's x and y reflect those changes. You could even point a tween'sonUpdate to the Draggable's update method to ensure things are synchronized throughout a tween.
Link to comment
Share on other sites

I don't blame you for thinking that - it probably isn't as clear as it should be. "x" and "y" are properties of Draggable that get updated even if you're using "left" and "top". In other words, if you set type:"left", the Draggable's "x" will reflect the current "left" property. left = x, top = y, scrollLeft = x, scrollTop = y, rotation = x. Why? Because they're pretty much all related to a horizontal or vertical plane and we wanted to have some level of consistency so that we didn't have to instantiate 7 different properties on a Draggable. 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×