SteveS

Can you provide at least a video of the issue? Are you saying when the page loads already scrolled their is a problem?

Yeah, that's what I ended up doing but wanted to confirm the matchMedia behavior and see if it was something I didn't unerstand. Thanks!

No, the codepen no longer works as expected now that I have updated it. To see the issue, resize the viewport to be lower than 800px and inspect the transform property on the #content element. Now when it reverts it doesn't revert to 0 and is instead still transformed by some amount.

Yeah, looks like it's reverting such that the right side of the element is flush instead of resetting the value to 0

Yes, I am on version 3.11.4 It looks like if I remove the cleanup function the behavior changes. Instead of not changing at all, it instead changes to a static negative amount. Seems to be connected to the fact that the element is wider than the viewport when the change happens. I updated the codepen so that the scroll elements are wider than the 800px breakpoint and am now seeing a similar effect.

I'm running into an odd issue. In my project I am using draggable to get a slider exactly like the one contained in the codepen. I've copied and pasted the styles, html, and JS with the exception of IDs. However, in my project, upon leaving the bounds of the media query the X transform on the "track" is not reverting. My project is in Astro using Tailwind CSS, TypeScript, and HTML. I tried replacing the tailwind styles with regular styles to match the codepen with no change. To confirm: upon reaching the bottom break point, the transform3d property of the dragged element is unchanged. In the codepen, everything gets set to 0. Edit: I have updated the codepen so that the scroll elements are larger than the viewport when the media query break happens and now the error appears. What could possibly be preventing the matchMedia from reverting the draggable in my project, but not a codepen? In theory, Astro generates HTML, CSS, and JS that just runs in the browser. I wouldn't expect any deviation in behavior. Above 800px: Below 800px (content is shifted left, no longer draggable):

Not as well established, but something I have been playing with is Rapier.js Its documentation isn't the best yet and there's few resources on it, but it is still pretty cool if you want to try it out.

Can you explain what the interaction is supposed to look like?

I would look at the existing ways of integrating scrollTrigger with other smooth scrolling libraries like locomotive scroll or AsScroll

bad on me for not checking the flickity docs ?

Ah, I see. Yeah. If flickity won't provide a callback for when the slide changes then mutation observer should work. This article provides a function to watch for changes in className: https://nikitahl.com/listen-for-class-change-in-javascript

Ok. Well, I still don't understand what this is supposed to look like, but it seems that the issue you are having is that the tween doesn't fire when the class is added or removed. That is expected behavior since you need to tell the tween when to fire. If flickity provides a callback for when a new item is selected, you could put the logic in there. Alternatively, you can use the JS Mutation Observer to watch for when the class changes.

And why are you adding a scrollTrigger to the tween?

So how is this supposed to interact with flickity?

@chuck77 I haven't looked closely since the link in your OP is going to an error page for me, but I'll give my best explanation. When you use GSAP + React, the biggest issue to overcome is the fact that GSAP is not Reactive, nor does it "live" in react. There are some ways you can sort of get it to interact with state documented in the Advanced GSAP + React guide, but generally I would avoid it unless you know exactly what you are doing. If you are instancing a scrollTrigger that consumes a piece of state, that means the function/tween that uses the scrollTrigger must be re-run to create itself with the new value in mind. Rodrigo's example isn't using React Context, it is using gsap.context(). He isn't using React State either. Instead he creates the ScrollTrigger and puts it in a React Ref so that it persists across re-renders. Nothing needs to be stored in React State because all that information is maintained withing ScrollTrigger itself. If you are new to GSAP, I highly, HIGHLY recommend getting some experience with in in Vanilla JS first. React is a cool tool, but it only causes problems when it comes to animations. Figure out the vanilla implementation first and try implementing it from there.

Yes. This is probably something you'd have to to with a combination of quickTo and ScrollTrigger. This post: Discusses how to achieve an lerp like effect similar to what you are trying to achieve. Instead of attaching the logic to a mousemove event listener, you put it in a scrollTrigger onUpdate.

What are you doing to the elements after you select them?

I'm using a point grid to handle liveSnap. When using a function to determine when something snaps, it is easy to check when a snap occurs like above, but if I am passing a points array, the snapping is handled inside of Draggable and I can't tell when something snaps.

Use case: 1. User drags element over a snappable point 2. Element changes width to match point 3. User drags element to other point 4. Element changes width to accommodate new area

Coming back to this again from another angle: knowing when an element has snapped during liveSnap when using the `points:` property. It doesn't seem like there is any way to do that similar to the previously mentioned solution.

I am attempting a solution where I manually update the draggable instance "vars" in an effect that is tracking the state I want to sync. It might work but it still isn't pretty.

Is there any way to easily access React state from inside a draggable instance? Not even storing values in refs lets me access and update them. I've managed some workarounds with external state managers, but it takes an insane amount of work. I'm hoping I'm missing something simple.

To my knowledge, you should avoid combining ScrollTrigger and scroll-behavior: smooth. The reason is that you don't want the two fighting over what the true scroll behavior is, and when you use scroll-behavior smooth, it is handled by CSS and not accessible in the same way to GSAP. Is there a reason you need scroll-behavior smooth?

What are you trying to tween? If your element doesn't have a progress property it will throw an error.

Yes, that's what I was getting at. Had something similar earlier but didn't make use of this.x Very nice, thanks.