BowserKingKoopa

"Oh ok so you're not saying 'I can't pinch zoom a webpage while using draggable?' you're saying 'why can I not pinch zoom in on an element?'" I think what I'm saying is much closer to the first thing than the second thing. Draggable is preventing pinch/zoom from working. True it's only when my fingers are on a Draggable. But when Draggables are full screen (which I believe is a valid use case for Draggable and is featured in the demos) your fingers are always on a Draggable. Besides, users don't know what a Draggable is, they just know that your website makes their phone feel broken. "In that case it's not that it doesn't work, it's just that it's not a feature in the first place" I'm not asking Draggable to do pinch/zoom. I'm asking Draggable to stop interfering with the phone's native pinch/zoom. "It's a plugin for drag events not for multi-touch." Agreed, so don't break my pinch/zoom. -R

Even if I could get that to work I'm reluctant to try and replace iPhones perfect pinch/zoom with a fake JavaScript solution. I want the phone/browser to just work normally even if there happens to be a Draggable under your fingers. Draggable is preventing the pinch/zoom from happening (I believe that must be the case right? Draggable is the thing preventing the pinch/zoom). Why can't it just not do that? -R

The original post was a little different. I was referring to later messages in the post talking about getting multitouch things like pinch/zoom to actually work. It's been four years since that post and I was wondering if any progress has been made on that front or if a solution has come up. On one hand Draggable is described as "Works great on tablets, phones, and desktop browsers" which isn't really true when something as integral to the iPhone (for example) experience as pinch/zoom doesn't work. On the other hand maybe my use case is unusual and Draggable being used for large or full screen images isn't the intended use? Maybe it's for dragging tiny elements around? If you're dragging tiny elements around you might not notice that a particular pinch/zoom gesture didn't work. But when you're dragging full screen images around it feels like your phone is broken. I know they don't work and I still instinctively pinch/zoom. -R

As mentioned in this old post: Pinch Zoom doesn't work inside Draggable. I'm using Draggable to scroll large full screen images around but this breaks Pinch Zoom on touch devices. On iPhone, for example, this feels completely broken. Has anyone found a solution for this? -R

Hi Rodrigo, I'm currently using the plugin I linked (https://github.com/hzdg/gsap-react-plugin) with the newest version of React without any problem. It's a really simple plugin, maybe 50 lines of code. All it does it redirect all GSAP animations that target a React component through the React setState mechanism. So while I'm not the author of it, I think there hasn't been any updates because it's done. It's the opposite of the approach you mentioned: "not piping anything GSAP related through the state to avoid rendering the React component on every GSAP tick". I tried that at first and quickly got tangled up. It was hard. I found that in my game I often needed React and GSAP to manipulate the same properties and trying to sort it all out became a source of many weird bugs. So now I'm piping EVERYTHING through React (using that plugin). So far so good. And it lets me keep my mind in "React mode".

The thing about React is not performance gains. Sometimes you get some because it knows all the hacks and tricks and minutiae of DOM manipulation (as does GSAP). But that's not the thing. The thing is Immediate Mode (yay!) vs Retained Mode (yuck). React lets you code as if the Retained Mode DOM was, in fact, Immediate Mode. Immediate Mode is such a big win I'd trade performance for it. I'd trade GSAP for it (though I don't want to). I'd trade almost anything for it. It's that big of a win. It's the proper API for building a UI. The performance hit for putting GSAP on top of React hasn't proven to be noticeable in my current game project. I'm using https://github.com/hzdg/gsap-react-plugin which pipes all my GSAP animations through React's setState mechanism. I've suffered no noticeable performance hit for doing so. (It might not even be slower. Probably depends on who is better at DOM manipulation, GSAP or React). So I'm quite happily using GSAP with React. I'd be happier if GSAP had a React Component API though, which is what this post was about.

Nothing's really breaking. There's nothing to really fix. (Except your entire way of thinking. Ha! React!). GSAP and React just don't play together well. This blog post does a good job of describing the problem as well as proposing a good example of a solution: https://fabric.io/blog/introducing-the-velocityreact-library Hooking into React lifecycle methods to fire off GSAP calls is a hack. What the React developer really wants to do is describe the animation declaratively in the Render method using React components. The linked blog post shows a possible way of doing that that looks like a good start to me. It's more like CSS animations where you say 'when this property is animated do it like this'. Think of it as us wanting GSAP in another language, the language being React Components. Look into React. The Kool-Aid tastes great! Read that blog post. It presents a nice idea of what animation components might look like in a React style.

The problem is fundamental. Imperative GSAP code doesn't fit well with declarative React code. The problem isn't specific to GSAP. React does not have a good animation story at the moment. This is something I hope GSAP might address in the future. The blog post I linked describes the problem well: "React and animation don’t actually play well together at first. There’s an impedance mis-match: React’s power stems from abstracting away the state transitions in your UIs (it does them quickly and correctly, enabling the declarative paradigm we’ve come to love), while animations live entirely within those state transitions." and "To integrate smoothly with React’s declarative nature, we’ll need our animation behavior to be fully described by the output of our render methods: a desired end state." https://fabric.io/blog/introducing-the-velocityreact-library Their solution was a set of React components that let them create animations in a React friendly way. Something like that for GSAP would be amazing. GSAP should embrace React.

I'm currently using GSAP in ReactJS (via https://github.com/hzdg/gsap-react-plugin). But it's difficult because it's an awkward mix of functional React code and imperative GSAP code. And you have to jump through hoops to make sure GSAP doesn't interfere with the React rendering. We desperately need something like this: https://fabric.io/blog/introducing-the-velocityreact-library -Ryan

So it's definitely a Chrome thing. Other browsers look good for me as well. Using an img tag instead of a background image is a bit of a pain in the actual game but still it's something I might be able to get working. Thanks so much for your help.

Except if I do the same transform using CSS transitions it's silky smooth. So it's not beyond the capability of the browser by any stretch. It has to do with the way Draggable is doing the animation. The demo you made with the smaller image is still pretty choppy. I still think something weird is going on in Draggable.

I have a container and inside the container I have my "game". I drag the game view around using Draggable. I tried to implement a zoom feature and found that when I animate the Scale of the Draggable it is very slow and choppy, as demonstrated in my codepen. The same zoom feature implemented with CSS Transitions is smooth as silk (but I can't use that in my actual game because it interferes with Draggable. They fight over the transform). Can you help me figure out why this animation is so slow and if there's a better way to do this? Thanks. -Ryan Edit: The problem is most apparent in Chrome.

Overwrite: none is not behaving how I imagined it would. In my codepen example I imagined that the second tween would be ignored because the first tween is already animating the element's "width". Instead it seems like the first tween is being overwritten despite overwrite being set to "none". Am I misunderstanding overwrite? Is there a way to accomplish what I want (where the second tween would be ignored because another tween has already 'claimed' the right to animated "width"?) http://codepen.io/anon/pen/BoJMvw Thanks for any help. -Ryan

This is working perfect for me. Thank you. However, it seems to be working without me having to call update(). When is calling update necessary? Updated codepen: http://codepen.io/anon/pen/byuor

What is the best way to control a Draggable element's scroll position programmatically? I'd like to be able to explicitly set the draggable's x, y position from code. Setting the draggable's x and y properties doesn't seem to do anything (the docs list them as 'read only'.