Leaderboard

Fixed version so you can see the difference. https://stackblitz.com/edit/react-xugc6c?file=index.js

Here's a demo. I only want the box I click on to animate. That obviously does not happen as both boxes animate. https://stackblitz.com/edit/react-hwyoaw?file=index.js If you update the demo to use refs it will work correctly.

You're not targeting the virtual DOM elements because you really don't have access to the virtual DOM. You're targeting real DOM elements, and you probably shouldn't being using CSS selectors. The reason should be obvious regardless of what library/framework you're using. It's all about locality. Passing in a CSS selector to GSAP runs document.querySelectorAll(), so it's going to search the entire DOM for matching elements. That will cause problems if you use a component more than once, but want to animate an element inside a specific component. Using refs eliminates that problem.

Ahhhhh! That really rings a bell now, doh! Thanks so much Shaun and Jack!!

Hi @Pete Barr, There are just 2 ways to set/get object properties in Javascript ... dot notation and bracket notation (like addressing an array index). With the dot syntax you don't have any wiggle room with dynamic keys ... as you can not do the following someObject."property_"+i = "someValue"; but you can do someObject["property_"+i] = "someValue"; So @GreenSock was using that syntax to show you how to get at a dynamic variable (which is actually a dynamic property key). It might not be so clear because what is being passed as the key is the variable `myWeight` which was previously set to the value of "--myWeight"+(index+1) which is essentially the same as vars["--myWeight"+(index+1)] = 900; which addresses when evaluated, for example vars["--myWeight1"] = 900; vars["--myWeight2"] = 900; vars["--myWeight3"] = 900; vars["--myWeight4"] = 900; // etc Which, if syntax allowed, would be like vars.--myWeight1 = 900; vars.--myWeight2 = 900; vars.--myWeight3 = 900; vars.--myWeight4 = 900; When using dot syntax, vars.myWeight = 900; "myWeight" would never evaluate to the dynamic properties you're looking for ... the script would be looking for precisely the property "myWeight" in that object (which does not exist). I hope this helps! Shaun

Thanks Jack! I'm pretty sure that I had the same issue in the past, but I thought it is my fault I create several timelines at the start of the application for the same element and those events started based on events/conditions. This is why I must pause the timeline when created. Also each timeline can start with a different transform origin, this is why I need to set the transform origin at the start of the timeline. I know which is the first timeline to play, so I need the fromTo to immediateRender: true. In my real world scenario rotationZ might start with 45deg, so it has to get its initial position when I place the fromTo into the timeline. As I know the starting position of the element, maybe I should do an initial set of values to the element at application start, so immediateRender could be false. Not a bad idea, will try. My timelines might be repeated, so it would be a lot easier if set could stay on the timeline. Based on your detailed explanation, it seems like that the workaround for the transform origin z-offset cached to early for the fromTo tween and does not use what is set in the to. For example the same scenario with x is working fine: https://codepen.io/anon/pen/OrNQmw

Hi @namisuki, This could be a version ... Happy folding ... Mikel

Well, you've got a very odd scenario here that's a bit tricky. First, let me give you a few solutions you can choose from: Don't pause the timeline initially. There's absolutely no reason to do that here - you play() it on the same tick, so it's useless. Set immediateRender:false on the fromTo() tween. Put the transformOrigin in the "from" part of the fromTo() (eliminate the set() altogether). Don't embed the set() in the timeline - just do a TweenMax.set() first, before creating the timeline. The problem you ran into would only happen on a paused timeline with a set() that's placed exactly at the beginning and a transform-related fromTo() in the same timeline. In all our years of having GSAP in the wild, I don't think anyone else has reported anything like this - so gold star for you! By default, fromTo() tweens have immediateRender set to true, but the set(), when in a timeline, will actually check to see if it's at the current time of that parent timeline and if so (and if the parent isn't paused), it'll set immediateRender:true. So in your case, fromTo() was rendering the transforms FIRST, and then when you play(), it's triggering the set() but that's too late - the fromTo() has already recorded its starting/ending values. And when you do the first transform on an element, GSAP must set its transformOrigin in order to work around some browser bugs. So again, your scenario was very uncommon. I think I've got a workaround I'll put into the next release for this particular scenario. Let me know if you'd like to get an early copy.

Hi, @GreenSock is right. The main concern when dealing with any type of shadow dom library/framework is what's called DOM reconciliation (something @OSUblake has more knowledge than I am). Here's what React's official docs say about reconciliation: https://reactjs.org/docs/reconciliation.html But back on the specific question, yeah the issue is that GSAP doesn't have the slightest idea of what could make the resulting DOM to change and as Jack mentioned is a bad idea performance-wise, so GSAP takes care of it's own end and so does React (and Vue and other shadow dom libraries as well). They work in what's called a reactive way. Something changes that makes necessary a DOM update. The good news is that all those tools offer what's normally called lifecycle methods/hooks (do not confuse with the new hooks API introduced by React) which help you do stuff, before or after the DOM is going to change as a result of a state property being mutated. That's why in every piece of documentation is highly discouraged to reach and manipulate the DOM directly, hence the usage of references (refs). The only thing you have to be careful about is that if an animation is running a somehow your DOM could change and remove the tween target, be sure to kill those animations in order to prevent an error being thrown. Here is where the lifecycle methods are handy because you can use them to create the animations once the DOM has been updated and you can be sure that the elements you want to animate are present and you wont get an error or unwanted behaviour, and that you will be able to act before those elements are removed. As you mention, seems that you've been selecting elements after those elements are rendered, so they are there and as you can see, since that's just good ol' plain javascript, it works. But is safer and more appropriate to follow each library's guides and patterns to do so. Finally, I've check some things about React hooks but I haven't mix them with GSAP for two reasons. First, I haven't had enough time. Two, keep in mind that hooks are on the roadmap of version 17 of React, they are still a proposal and the React team is gathering information, bugs and opinions from the community as well as doing their own tests, so thechance that the API could have some major differences from what it is now is not small, so I try to stay away from using them in any type of production code. Also I don't like to invest a lot of time in things that are not even in beta or at least release candidate (RC version), because of changes in the future. But as you mention the effect hook is an easier way of triggering something because a state change. Hooks are very nice and a great addition to React and most devs I've shared some thoughts on them, are very in to hooks (they are hooked ), so they are here to stay most likely, but changes in their API will be inevitable moving toward a stable release. I'll see if I can whip something using hooks, but you caught me in a couple of bad days, so perhaps tomorrow night or Friday I could get into that. In the mean time feel free to continue the discussion here or if you want you can PM me. Happy Tweening!!

I'm not much of a React/Vue/framework guy so I'm not in a good position to answer this, but hopefully @Rodrigo (the author of that article) or one of the other moderators with experience in that stuff ( @Dipscom, @OSUblake ) will chime in. My suspicion is that React/Vue like to swap things out from underneath you in the virtual DOM, so they prefer that you use their own way of referencing things so that you don't have references to stuff that they nuked. I could be wrong. Either way, though, in order for GSAP to work they can't just willy-nilly swap stuff out mid-animation because those instances are referenced by GSAP. In other words, if you've got a <div id="thing"></div> and GSAP starts animating that (maybe it got the reference via a "#thing" selector) and then React is like "yeah, I'm just gonna nuke that and build another <div id="thing"></div> in its place), that ain't gonna fly. It'd be extremely inefficient too if GSAP had to keep on re-querying the DOM (or virtual DOM) to update its reference 60 times per second, you know? So it seems to me like CSS selectors probably work fine as long as your animation is starting immediately (and React/Vue aren't swapping stuff out mid-tween), but using the ref instead ensures that scheduled tweens have the best chance of using the proper element if React/Vue decided to rewrite something in the virtual DOM between when your animation code was evaluated and when it actually begins. Again, just my guess. I'm sure someone else can offer a "real" answer