Leaderboard

Nice work, @PointC! The only thing that kinda bugged me usability-wise was that if I clicked on another menu item before the animation completes, it basically ignored my click, so it felt unresponsive. As a user, I'd prefer this behavior: Just a minor tweak, but it just "feels" more natural to me Now you can click around as quickly as you want.

First of all, welcome to the forums @b0dg4n! And thanks for joining Club GreenSock! Sorry to hear about the trouble. It sounds like you're using the wrong files (UMD rather than ES modules). The simplest solution is probably to "npm install gsap --save-dev" for the main/public stuff, and then for the bonus plugins make sure you're using the files in the "bonus-files-for-npm-users" folder of the zip. Those are ES Modules (well, there's also a /umd/ subfolder if you NEED that format). If your build process involves tree shaking, you may also need to reference ThrowPropsPlugin somewhere in your own code just so that Webpack doesn't dump it inadvertently, like: import ThrowPropsPlugin from "../src/gsap-bonus/ThrowPropsPlugin.js"; const plugin = ThrowPropsPlugin; //just to keep tree shaking from dumping it. That assumes you put the bonus files in a src/gsap-bonus/ directory of course (doesn't really matter what you name it...just put whatever path you want there for your particular setup). See https://greensock.com/docs/NPMUsage Does that help? If you're still having trouble, please provide a reduced test case on stackblitz or codepen or something like that so we can see what's going on. Feel free to private message me with details so that you're not posting the actual bonus plugins somewhere public. I'm sure we can help get things squared away for you.

Yeah, it is indeed tricky to understand what's happening because there are a lot of illusions. I think this is kinda what you're looking for, right?: Just remember that what LOOKS like it's spinning isn't actually all one piece (with a front and back). It's a clone of the "from" <div> that animates and then immediately gets removed from the DOM after forcing the "to" <div> to be set to visibility:visible. It's a slight-of-hand in a sense. So you can't be fading one in at the same time that the other is fading out because they're not both on the screen at the same time.

@GreenSock that's amazing - all good now! Thanks so much for this! It works just fine right now. The only thing I could suggest is maybe add a reference to the NPM usage on the plugin page, for other ones that might be in my position.

I would, but I have a team coming in to sweep my office for bugs. I need to find out how you were reading my mind earlier. Perhaps our Moderator badges contain a chip that monitors brainwaves?

Let's just keep going back and forth enhancing it - this will be fun!

uh-oh, I'm in a weird weekend contest with Jack. ? It's so strange that you made that change as I was literally just thinking about making another version that wouldn't make the user wait and my email chimed with your post. Now I don't have to do the work. Well done.

I agree with all the answers/suggestions provided but I also just wanted to say that if you're having performance problems, it's very unlikely that it's related to GSAP. Typically less than 5% of the CPU load has anything to do with GSAP - the vast majority is the browser's graphics rendering/painting and reflow calculations. So, for example, if you're animating a bunch of huge objects that require repainting millions of pixels on each frame, you might want to consider reworking things so that you're not putting so much of a load on the browser in terms of graphics rendering. If you still need some help, please provide a reduced test case in codepen so we can see what's going on. Happy tweening!

Hi @flowen You can pre-record the values like this: tl.progress(1).progress(0); That will make the virtual playhead move to the end and then back to the beginning of the timeline. That can sometimes help with a slight stutter on the first play. If that doesn't fix it for you, a demo would be most helpful. Happy tweening.

yup, thats exactly what I was looking for. Thanks!

Yes, exactly. I'm always VERY cautious about making changes that'd affect legacy code but in this case I wonder if it's best to just bite the bullet and make the change now because: If someone specifically applied a Draggable to an element that's "clickable", they probably expect it to be draggable anyway without having to set dragClickables:true. In other words, this is probably the most intuitive behavior anyway, thus changing the current default behavior is favorable in most cases. React is relatively popular and I'm concerned that too many people will run into this unintuitive behavior and blame Draggable as being glitchy. If this change does affect legacy code, it's relatively easy to fix by setting dragClickables:false. Then again, I may be missing an angle here that should be considered. Thoughts?

It looks like you're expecting event callbacks to fire many times on a single event, but that's not how it works. If your goal is to have a function called at a particular time in a timeline when the playhead moves past it in either direction (forward or backward), use a regular call() or addCallback() on the timeline.

The problem is that you've got a tween that has its "onStart" callback in the wrong place. It's in the "from" vars instead of the "to" vars: //BAD: .fromTo($('.num_' + initTabNum), 0.75, {onStart: step_2, y: -100}, {y: 0, ease: Elastic.easeOut, immediateRender:false}); //GOOD: .fromTo($('.num_' + initTabNum), 0.75, {y: -100}, {onStart: step_2, y: 0, ease: Elastic.easeOut, immediateRender:false}); Does that help?

Mostly I just realized i've been doing it all wrong! I had been creating separate graphics objects for each element, and then mostly trying to tween their x, y, width, height to achieve my goals. Seeing your example and understanding that you can use Greensock to tween properties on data objects (which are then rendered in a loop) makes so much more sense. I realize this is probably Graphics Programming 101, but it was helpful to me. Thanks for taking the time to explain @OSUblake. I appreciate it.