Search the Community

import React from "react"; import "./FollowImage.css" import gsap from "gsap"; import Image from "react-bootstrap/esm/Image"; function FollowImage (){ let FollowBox = "#Wrap .FollowBox"; gsap.set(FollowBox, { xPercent: 1, yPercent: 1, scale: 0 }); const MyDiv = document.getElementById('Wrap') function clamp(num, min, max) { return num <= min ? min : num >= max ? max : num } window.addEventListener("mousemove", (e) => { gsap.to(FollowBox, { duration: 0.5, overwrite: "auto", x: clamp(-100+e.clientX - e.target.offsetLeft,-50,150), y: clamp(-100+e.clientY- e.target.offsetTop,0,150), stagger: 0.15, ease: "none" }); }); return ( <div id="Wrap"> <Image id="FollowBox" className="FollowBox" src="1000x600(mykhaylo).png" alt="" /> <Image className="FollowBox" src="1000x600(music).png" alt="" /> </div> ) } export default FollowImage; This is my current code, so far I failed to translate it for codepen.

Can you let me know exactly what the box animation is doing? If it's simple I'd probably just tween it dynamically and use overwrite modes instead of a timeline?

Or maybe? https://codepen.io/GreenSock/pen/bGvOKMw?editors=0010 You were using the circle itself as the trigger element which is an issue because that trigger is moving, Also scrollTriggers are immediately rendered so you'd want to stop that from happening so it doesn't 'precalculate' the animation values. Then pop an overwrite 'auto' on the tween itself so it take priority over the initial load tween

Hi. I'm trying to animate a circular shape on scroll that sometimes might happen while a previous Tween with the same element is still animating. If you take a look at the codepen, once the page is loaded, the circular shape is being animated, but if you scroll while it's still animating, it causes a jump on the circle. The espected behaviour is that if you scroll while the Tween is animating, the animation should continue from the previous Scale value. I have already tried "overwrite: true" but that doesn't seem to help in this case.

I couldn't reproduce either. Are you able to reproduce it on that CodePen even one time @celli? This is definitely a mistake: box.addEventListener("mouseleave", function () { return tl.reverse(); tl.totalProgress(1).kill(); // <- THIS LINE WILL NEVER RUN!!! }); You have a return statement on that first line which totally bails out of the function immediately, thus that next line never gets executed. But even if it did, you're having the opposite effect that you seem to want. Forcing it to a totalProgress(1) make it go to the END of the timeline, not the start. But aren't you trying to reverse it (to go backward toward the start)? Why would you then try to jump to the end and kill it? My guess is that your real project has a fundamental difference that's the root cause of the problem. You mentioned that it "gets stuck". That sounds to me like you must be killing it somewhere -or- you're overwriting somewhere. Do you have overwrite: true anywhere that might be getting triggered? In order to effectively troubleshoot, we really need a minimal demo that clearly shows the problem but the one you provided seems to never show the problem which makes it tough. Any chance you could provide a broken demo?

That would create significant logic problems. Trust me - a feature like that would be a disaster. Imagine you've got a "power4.out" ease on a tween and then halfway through you call reverse() and you want it to use a "power2.in" ease in reverse. Well at 50%, the interpolation would be in a completely different place, so you'd suddenly see a jump. For example, let's say you're tweening element.x from 0 to 100. With a power4.out tween, 50% might render element.x at 94.342, but a power2.in may render it at 29.851. So at the moment of reversing, element.x would JUMP from 94.342 to 29.851. GSAP already allows for the yoyo phase of an ease to be different and that's possible because it only switches when it is all the way complete (thus the eases would render identically). See the yoyoEase property. The most common way of dealing with the situation you described where you have a menu opening animation that you don't want a true reverse on (because you're CHANGING the ease) is to dynamically create it at that time. Don't pre-bake everything into a single timeline. Sorta like: function open() { gsap.to(..., {x: 100, ease: "power2", overwrite: true}) // and all the other parts... } function close() { gsap.to(..., {x: 0, ease: "power2", overwrite: true}); // and all the other parts... } I hope that helps.

I don't have time to do a deep dive, but it sounds like maybe you just need to do this: if (isOver) { gsap.to(tl, {timeScale: 0, duration: 1, overwrite: true}); } https://codepen.io/GreenSock/pen/QWmmgjd?editors=0010

I'm posting the final code down here: function BackgroundCloud(props){ // Current element let thisEl // Refreshes the component let isLoaded = useContext(props.pageLoaded) // Maxiumum left attribute that the cloud must reach & animation const maxLeft = useRef(0) const animation = useRef([]) function updateWindow(evt){ // If it is the first execution update the left parameter and set currentHeight & currentWidth if(!evt){ resetComponent() } // --> This code must be executed in both vertical and horizontal resize <-- maxLeft.current = 2 * thisEl.width() + $(window).width() // Adapting cloud to new top const parent = thisEl.parent().parent().parent() const fromTop = parent.offset().top const parentDistance = fromTop + parent.height() / 2 let top = props.top if(top.includes("vh")){ top = top.replace("vh", "") top = top * 0.01 top = $(window).height() * top }else if(top.includes("px")){ top = top.replace("px", "") } thisEl.css("--top", String(parentDistance + top).concat("px")) // Delete every ongoing animation killAnimation() // Create a new animation animation.current.push(gsap.to(thisEl, {left: maxLeft.current, duration: props.duration, ease: Linear.easeNone, onComplete: resetComponent})) } // Delete every ongoin animation function killAnimation(){ for(let i = 0; i < animation.current.length; i++){ animation.current[i].kill() } animation.current = [] } // Exec when the site is loaded/the component refreshed useEffect(() => { if(isLoaded){ updateWindow() $(window).on("resize", updateWindow) } }, []) // Reset a cloud (called when the component reaches the end) function resetComponent(){ thisEl = $(`#${props.propId}`) thisEl.css("left", -2 * thisEl.width()) killAnimation() animation.current.push(gsap.to(thisEl, {left: maxLeft.current, duration: props.duration, ease: Linear.easeNone, delay: props.delay, onComplete: resetComponent})) } // Return default cloud return( <div className="backgroundCloudContainer"> <img src={props.background} className="backgroundCloud" id={props.propId} draggable="false" alt={props.propId} style={{ "--z-index": props.zIndex, "--top": props.top, "--scale": props.scale }}/> </div> ) } To fix the problem I did the following things: 1) Using an array to store every animation I create (so I can .kill() everything) 2) Using useRef() instead of saving data in plain variables 3) Fixed the event listeners because I inserted the jquery .off() method that removes every listener from the element that, of course, made my solution not working Now I'm planning to remove the array and setting overwrite to "auto" or true so I'll save a piece of performance. Anyway, thanks for helping me. Hope that the problem I had will help someone else : D

It's pretty tough to troubleshoot without a minimal demo - the issue could be caused by CSS, markup, a third party library, your browser, an external script that's totally unrelated to GSAP, etc. Would you please provide a very simple CodePen or CodeSandbox that demonstrates the issue? Please don't include your whole project. Just some colored <div> elements and the GSAP code is best (avoid frameworks if possible). See if you can recreate the issue with as few dependancies as possible. If not, incrementally add code bit by bit until it breaks. Usually people solve their own issues during this process! If not, then at least we have a reduced test case which greatly increases your chances of getting a relevant answer. Here's a React template. Once we see an isolated demo, we'll do our best to jump in and help with your GSAP-specific questions. Setting overwrite to "auto" or true can be good, but it's important that you understand what's going on and what that's solving so that you can ensure it's not just a band-aid that covers over something like creating a bunch of conflicting animations unnecessarily.

Before trying those things together, I noticed that React calls multiple times my function, so, is enabling overwriting a good way for "skipping" some problems? And is gsap.defaults({overwrite: "auto"}); a good way for enabling it? (From: )

Ah ok! So currently if it leaves a black section to enter another black section it's trying to reverse the animation and then immediately play it again. I think you may be able to get around this with a different overwrite mode. But I think I'd pop the tween out into a callback instead, then check the incoming section's color and update it accordingly. https://codepen.io/GreenSock/pen/eYMVNYg That seems to work without any overwriting needed and no visual flickers. ☺️ Hope this helps!

That's the idea. You can also set gsap.defaults before gsap.registerPlugin too... My first few lines on a typical GSAP project are: 'use strict'; gsap.defaults({overwrite: "auto"}); gsap.registerPlugin(CSSRulePlugin, ScrollToPlugin, ScrollTrigger, TextPlugin);

That has to do with the plumbing in your app - we really try to stay focused on GSAP-specific things here. But the general idea is to only add those even handlers once. Or if you're gonna add them multiple times, make sure you remove the old one before adding the new one each time (so there's always only one). You can gsap.killTweensOf(Cursor) if you want, but I'm reluctant to suggest that because it's just shielding you from the real, fundamental issue in your app (creating all those listeners). You can set overwrite: "auto" to have GSAP try to find conflicts when the new animation renders for the first time. But again, that's a band-aid here. Good luck!

No, it's not a GSAP bug - it's a problem with your code: you keep adding more and more event listeners to the same element each time you navigate. So for example, if you go to 3 pages and then you roll over the "Fixed button", it will call 3 event handlers, firing 3 identical animations that are all fighting for control of the same properties of the same element. The best way to solve this is for you to not add a bunch of the same event handlers. Make sure you removeEventListener() when you leave the page, or add conditional logic to not add a new event handler when there's already one added. Alternatively, you could set overwrite: true or overwrite: "auto" on the tween(s) but even though that'd technically prevent conflicts, it's just masking the fundamental problem in your code. It's bad for performance to just keep stacking up more and more event handlers like that. If your user visits 30 pages, you really don't want a rollover to fire of 30 different handlers, creating 30 new animations and overwriting 29 of them. Does that clear things up?

Quick question if anyone minds sparing some of their knowledge Like the overwrite property prevents previous animations effecting an element once another has started, is it possible to prevent an onComplete from a previous animation running? I've basically got a click event listener that fires off an animation, and onComplete deletes an element. But the element may or may not be there once the event handler runs again. I'd post a codepen, but to replicate some of the (awkward) design choices I'm working with it would be massive and probably just complicate things, so I was wondering if there was anything obvious I should be looking to do, or if there were any useful approaches I should think about when dealing with overlapping animations like this? Thanks!

Actually it looks like it doesn't like interrupting the tween fired in the leave event. I can't use xTo for that because it has a dynamic ease applied. I wonder why it doesn't overwrite it.

We love helping with GSAP-related questions, but unfortunately we just don't have the resources to provide free general consulting, logic troubleshooting, or "how do I recreate this cool effect I saw on another site?" tutorials. Of course anyone else is welcome to post an answer if they'd like - we just want to manage expectations. If I were you I'd approach this with single tweens per box and overwrite:true or auto. Maybe just focus on trying to swop one box between two different directions without scrollTrigger, then add some more boxes, then add in a ScrollTriggers with some callbacks and swop the direction over in the callbacks. Timelines are pre-calculated and a little less flexible for this sort of thing whereas tweens can be a bit more dynamic. Hope this helps a bit!

That's because of two problems in your code: You're creating an entirely new timeline on every click and you didn't kill() the old one or set overwrite: true on your tweens, so you've got conflicting tweens (multiple running that are fighting for control of the same property of the same elements). You've created a logic problem by using .from() tweens. Remember that .from() tweens use the CURRENT value as the destination. So let's say opacity starts at 1 and you do a .from(...{opacity: 1}). That would grab the current value (0) as the destination and IMMEDIATELY set opacity to 1 and then animate back to the destination (0). Great. But what if you click again quickly and opacity is at 0.98 when you create ANOTHER .from(...{opacity: 1}) tween? That would take the CURRENT value (0.98 in this case) and use it as the destination, thus your final animation would go from 1 to 0.98 and stop! Again, this is a logic problem in your code, not a bug in GSAP. There are many, many approaches you could take to solve this. Here is one where you just create your timeline up front once, and then simply toggle the playback direction via timeScale() on each click. I'm playing it 50% faster when closing: https://codepen.io/GreenSock/pen/oNqBjoK?editors=0010 Another solution would be to avoid .from tweens. Instead, you could gsap.set() the initial values and then animate to() the destination ones. And make sure you set overwrite: true on your tweens or it may be easier to just use a variable to remember the previous timeline so you can just .kill() it before creating the new one to avoid conflicts. Good luck!

Here's how I'd simplify it: https://codepen.io/GreenSock/pen/ExEZxOz?editors=0010 document.addEventListener("keyup", function(e) { let x, y; if (e.keyCode == 37) { // left arrow x = 100; } else if (e.keyCode == 38) { // up arrow y = 100; } else if (e.keyCode == 39) { // right arrow x = -100; } else if (e.keyCode == 40) { // down arrow y = -100; } if (x || y) { // if anything changed... let vars = {overwrite: true}; if (x) { vars.x = gsap.utils.clamp(bigDraggable.minX, bigDraggable.maxX, gsap.getProperty(bigImage, "x") + x); } else { vars.y = gsap.utils.clamp(bigDraggable.minY, bigDraggable.maxY, gsap.getProperty(bigImage, "y") + y); } gsap.to(bigImage, vars); e.preventDefault(); } }); Does that help?

Hey GSAP, first: you are awesome, thank you for these supercool libaries. We want to try out the new ScrollSmoother an got stuck on the following problem: We have a transform based animation with a scrollTrigger: let tl = gsap.timeline({ scrollTrigger:{ trigger: card, start: "top top", end: "bottom top", pinSpacing: false, pin: true, scrub: true, markers: false, }, defaults: { overwrite: "auto"} }); tl.fromTo(cardContent, {scale:1, opacity:1}, {scale: 0.8, opacity: 0.2}); tl.to(cardContent, {opacity:0}); To avoid conflicts with the transform values in the parent container animation (like "jumping" elements) , we use clearProps: true on the parent containers animation. This works like a charm, BUT: with using ScrollSmoother, the same effect of "jumping" elements ist back, as ScrollSmoother is based on transforms. I'm happy for any advice on how to deal with that. Thanks

Hi there! I have an issue using gsap. I'm using chakra and next on my project and i dont know why, but when I put the gsap to work it just make my svg weird, It look to overwrite something that should not happen. If you look at this little example and comment the line of useEffect you'll see what I mean. Hopeful for help, thanks https://codesandbox.io/s/portfolio-app-forked-20tos8?file=/components/projects.js

Thank You Cassie and Jack, there's of course some problem on the logic I'm pursuing, I know that the height of the page plays a key role on the animation I'm working on so I ask u this: if you were to make this animation from that I tried to explain the beginning, where would you start from? I don't want to bang my head unnecessarily If u think there's a better way to approach this animation I'm all ears The only caveat is that the two divs must be 100vh, always, at least when they're visible. (I tried with observer, it seems more fitting but I'm having similar problems with the changing page height Observer.create({ target: window, type: "wheel,touch,scroll", onUp: () => { move('100vh') }, onDown: () => { move(0) } }); function move(value) { gsap.to("#bottom", { "top": value, duration: 1.3, ease: Quart.easeInOut, // overwrite:true }) } )

Nope, that's fine because GSAP sets inline styles for maximum specificity. The only other thing I can think of is if maybe you accidentally killed the opacity animation? Like if after creating it, you did a DIFFERENT animation on that same element and set overwrite: true? I doubt it, but I'm just brainstorming. I would recommend setting an onUpdate on that particular tween so you know when it's being updated, and then open up Dev Tools and scroll to where it should be animating opacity and look in the console to see if it's firing. .to("#header-copy", { onUpdate: () => console.log("updated!"), opacity: 1, ease: "power1.inOut", duration: 30, }, 70); And is the opacity sticking at 0 or is it at 1 the whole time? I wonder if maybe it was not 0 when the tween rendered the first time, thus it's animating from 1 to 1 (no change).

We love helping with GSAP-related questions, but unfortunately we just don't have the resources to provide free general consulting and logic troubleshooting. Of course anyone else is welcome to post an answer if they'd like - we just want to manage expectations. You need to adjust your value on scroll. You could do that in a "scroll" event handler and look at the deltaY of the event perhaps. I would also strongly recommend using the gsap.quickTo() for your tweens that are constantly getting recreated on each mousemove event. The way you've got them set up now, you're creating new instances every time and they're all conflicting with each other because you didn't set overwrite: true (or "auto"). That's bad for performance. You can post in the "Jobs & Freelance" forum for paid consulting, or contact us directly. Otherwise, if you've got a GSAP-specific question, we'd be happy to try to help with that.

That code/logic looks very strange to me. I suspect @SteveS is correct, that you're overcomplicating and over-engineering things. You've got an onUpdate that's handling things differently based on the progress (odd - it's probably much cleaner to just use two ScrollTriggers) and then if it's more than 25%, you're calling moveAnimate() on EVERY update, over and over again which is creating a new tween each time and there's no overwrite set, so you're creating a ton of conflicting tweens that are all trying to control the same properties of the same elements. That's definitely a problem. The same goes for your xPercent tween in there - you're creating a new one over and over again. If you still need some help, I'd strongly recommend just simplifying things using a few colored <div> elements in CodePen and then post back here with your GSAP-specific question and we'd be happy to take a peek.